cwentland0 / perform Goto Github PK

Although the input of the centering and subtractive normalization profiles should still be separate, they can simply be rolled together under PERFORM's hood. The repeated summation of these two profiles in standardize_data() amounts to wasted FLOPS. Ideally, the centering profile can just be rolled into the subtractive normalization profile, and then center() can just be eliminated.

The function calc_adaptive_dtau() is not only incredibly slow, it is also not completely finished in the sense that it does not include all the robustness control capabilities included in GEMS. As I recall, the most expensive component of the adaptive dtau is calculating the mixture dynamic viscosity, which is not previously computed (it's only calculated at the face average). As such, the adaptive dtau should be completely fleshed out and some means of making the calculation less expensive should be sussed out.

Currently, only irreversible reactions are implemented. Obviously, even some of the simplest reduced mechanisms include a few reversible reactions, so an reversible reaction_model needs to be added. This obviously requires also including a routine for calculating the source term Jacobian.

As a stretch, it might be nice to also add a routine for loading reaction mechanism data from a Chemkin-format file. This would be especially useful for more complex mechanisms, instead of having to manually tabulate a bunch of stoichiometric coefficients and Arrhenius parameters.

Just about all docstrings in PERFORM only give very brief descriptions of what the class or function does. These need to be greatly expanded to include better details on their purpose, inputs and outputs, and how they fit into the broader code framework. This is especially true for the ROM class hierarchy, for when I implement automatic API documentation.

Currently, if requesting plots for density-species of the last species, the code will throw an error. This has already been corrected for just species mass fractions, so it can follow the same format by calculating the last species mass fraction field and multiplying by the density field.

Right now, calc_state_from_cons() and calc_state_from_prim() are very specific to the CaloricallyPerfectGas model, particularly the stagnation enthalpy calculations implicit in the energy and temperature calculations. This should be generalized to a given gas model, as this is very different for the upcoming TPG model (#18).

When performing real-time plotting, program startup will create a new GUI window for a given figure, but it's filled in with black and does not show the plotting axes. The first plotting iteration creates the dropdown menu bar in the GUI window, but again does not show the plotting axes. it is not until the second plotting iteration that the plotting axes finally show in the GUI window. This is particularly annoying for slow simulations like the TK-Keras autoencoder ROMs.

This may just be an issue with my own graphics drivers, but I have fixed this before (I think), so I'm pretty sure this can be resolved.

Instead of having to provide full NumPy binary files for the centering, subtractive normalization, and divisive normalization profiles, it would be more convenient to simply provide a single scalar value in the instance that scaling profiles are, indeed, constant values. Obviously the option to provide a full profile should remain intact.

The mean upstream rhoc and rhoc_p can be entirely determined from the mean flow pressure, temperature, and gas composition, and thus we don't need to supply rho_inlet and vel_inlet for the meanflow inlet boundary condition. These can just be precomputed at initialization.

The example case input files should be updated accordingly when this is finished.

Currently, non-solution fields (e.g. source term, RHS field) are calculated for all but the last time step's solution. To make this more in line with the solution output, and for methods like gappy POD which require the full snapshots of the residual field, these fields should be calculated at the last time step if the last time step is an output interval step. This can all occur within write_final_outputs.

Some folks prefer to use PyTorch, and I've been told it's even simpler than Keras. This amounts to just porting all the current TF-Keras autoencoder models (Galerkin, LSPG, and SP-LSVT) to PyTorch and benchmarking them against the TF-Keras models.

There are plenty of calculations for the species transport equation which are unnecessary when evolving a single-species simulation; these can just be skipped. It may be easier not to mess with sol_prim and sol_cons shapes and just leave the species mass fraction to avoid plotting errors.

Right now, calculating the time integrator residual is pretty specific to backwards differentiation methods. This should be generalized to a given ImplicitIntegrator child class, and this routine called from calc_res_jacob(). This should become more clear once an additional implicit time integrator is implemented.

An API guide for the ROM class hierarchy needs to be added to the RTD documentation. This includes automatic documentation of the various classes, as well as explanations of how everything fits together in very plain language. This will go a long way towards making it easier for new users to get up and running with adding new classes and routines to the ROM classes.

Currently, "testing" is performed by manually running the sample cases and checking that everything looks alright. Obviously this is unacceptable. Automated unit and regression testing needs to be integrated into the repo for more robust CI. Ideally, this would just go through GitHub Actions.

For regression tests, I figure it's good enough to test the solution output files of the shock_tube and transient_flame FOM, as that covers most of the solver routines. Unit tests can be much more targeted for the ROM routines as these are easy to devise analytical outcomes. The same goes for gas_models, reaction_models, and visualization classes.

Input and binary files that are required for testing and retrieved with wget are currently hosted on a personal Google Drive directory. These can be migrated to a more central, secure location within UM's AFS system (or MFile?) that will probably persist longer than my UM Google account.

The ic_params_file ingestion can be generalized to an arbitrary number of piecewise uniform regions, instead of the current "left"/"right" option. This would make for more interesting setups than those like the Sod shock tube.

This should also include error catching for when the user places split coordinates out of order or outside the spatial domain.

Right now, when running a linear projection ROM with hyper-reduction and plotting fields which are NOT the primitive or conservative field (such as the species source term), cells which are NOT sampled are still plotted. Since these are initialized with zeros, a value of zero is plotted for unsampled cells. This can lead to some weird jagged profiles. I see two options for resolving this issue:

1. Only plot the sampled cells. For relatively dense samplings this might be okay, but for sparse samplings the plots might be useless.
2. Recompute the full field, e.g. recompute the species source term at all cells, and plot the full field.

I think the second option is better, though it can make the visualization step much more expensive. Making the timing metrics more granular should improve this by making sure those calculations for plotting don't pollute the timings for the solver.

Right now, timing is provided only for the full solver runtime, which includes visualization and output. Considering visualization and writing to disk time can be pretty sporadic, it would be nice to at separate these from the solver runtime and report them separately. This would give a much more accurate measure, especially when measuring speedup of ROM methods.

When solving for the conservative variables (dual_time = False) with higher-order face reconstruction, the primitive field is still being reconstructed and then the conservative field is being computed from this. If solving for the conservative variables, the conservative field should be reconstructed at the faces and the primitive field computed from this.

The current routines for catching input parameters is not very robust. If given a default, the routine will attempt to cast all inputs as the type of the default. Issues arise when the default is NoneType, whereby the user is trusted to supply correct input. It may be better to pass both an expected type, while allowing the default to remain NoneType if that is a valid option.

The catch_list routine is also finicky, particularly for lists of lists. This routine should be able to throw an error if the given list (and sublists) is not the correct size. Assigning defaults should also be improved.

Additionally, if the parameter has no default and is not provided by the user, then it throws an KeyError. This is easy enough to recognize and correct, but it would be more helpful to have a routine that explains the issue in plain language with specific steps to correct the issue.

The routine for catching inlet/outlet parameters can also be improved/eliminated.

Providing a PDF in the repo just makes the Git history balloon, since it's a binary file and Git can't track changes very well. Thus, it would be a lot better to provide the raw LaTeX source and just leave it up to the user to compile the PDF. Worst case scenario, they can just load everything into Overleaf and compile it there, but it doesn't use much beyond fairly standard packages and should be relatively easy. Obviously, the PDF can be removed from the repo after that.

Currently, init_files and restart files only store a single solution profile. As a result, time integration always initializes from a cold start (first-order accuracy) regardless of the time integrator's order of accuracy requirements. Restart files and init_files should be able to provide the necessary time history to achieve full-order accuracy from initialization.

Right now, only the source term of the first species can be plotted. This is obviously not useful for multi-species systems, or even if you want to plot the source term of the final species (though this isn't calculated at the moment). The field and probe plotting routines need to be generalized to to account for multi-species configurations, along with the input parameters for defining which species source terms should be plotted.

This would be a big upgrade which creates an option to decompose the full spatial domain into several component SolutionDomains, with the ultimate goal of coupling ROM and FOM subdomains.Thus, each component domain is assigned its own SolutionDomain, and any of these component domains is a ROM, a RomDomain as well.

This would require a generic domain interface class. For FOMs, this is just a simple exchange of inlet/outlet solutions and gradients. For ROMs, more specialized interfaces are required. The treatment of boundary cells would obviously need to be altered, as well as the means for computing higher-order reconstructions for the boundary cell faces.

Need to add a general class interface for non-intrusive ROMs. This can be further broken down into those which still need a time integrator and those which do not. This will presumably require adding a dummy explicit time integrator that just acts to advance the solution from step to step.

I think that David Xu's TCN-CAE, Elizabeth Qian's Lift & Learn, and Romit Maulik's CAE-LSTM are good candidates to implement first and suss out a modular framework.

The RTD and solver theory documentation needs to be updated to include everything necessary to understanding and applying hyper-reduction for the linear projection ROM methods. The parameter index should also be updated with more detailed explanations for all input parameters.

Need to add a thermally-perfect gas gas_model, with all the necessary instance methods which are already implemented within CaloricallyPerfectGas. This will require new routines for loading the McBride transport and thermodynamic property polynomial tables. Routines for the derivatives and density and enthalpy can be ripped from GEMS.

Note, this will make solving in conservative variables (dual_time = False) particularly tricky, as backing out the stagnation enthalpy without access to temperature will require an iterative procedure. Nick had trouble with this, but such a routine already exists in GEMS. It should be easy enough to copy it from there.

Right now, the only means of tracking the iterative solve and steady solve residual norm is via the output to STDOUT. This is not very useful, especially when the numbers are streaming past at a fast rate. It would be much preferable to plot the time history of the residual in semi-log to get a better visual, especially for convergence of the steady solve. This will have to be a separate class from ProbePlot, but it may be useful to create a shared parent class which governs time history plots.

The flux, source, and solution Jacobians are incredibly convoluted, so it would be immensely useful to write these out in full in the solver theory documentation.

When solving for the conservative variables with an implicit time integrator (dual_time = False), the various residual fields are still normalized by res_norm_prim. Of course, this is not accurate and comparative conservative normalization factors should be used. I think the simplest way to go about this is to still take in user input for res_norm_prim (or rely on RES_NORM_PRIM_DEFAULT) and compute the equivalent conservative state. This can then be used for normalizing the conservative residual norms. I figure this is easier because people don't really think in terms of the conservative variables, and initial conditions are provided in terms of the primitive state.

When attempting to plot seven axes in a figure, an empty axes is placed in in the bottom-right portion of the figure. The bottom-center space is left completely blank, which is really strange. The problem does not appear when requesting five or eight plots, which correctly leave a space completely blank.

Right now, the unsteady heat release rate is not calculated. Considering this is a significant quantity of interest, this capability is crucial. Additionally, the unsteady heat release field should be able to be plotted, probed, and written to disk.

Providing an interface with Pressio for solving projection ROMs would be extremely useful for me to test that the current Galerkin and LSPG implementations work correctly, and also provide an implementation of windowed least-squares ROMs. I'm fairly certain that the Pressio interface can just be a child class of RomModel, as it already contains all the necessary routines for projection and so doesn't need to be part of ProjectionRom (I think).

Right now, all of the flux and source classes provide Jacobians with respect to the primitive variables only, which is fine for dual time-stepping (dual_time = True), but is not okay for normal time integration (dual_time = False). The current solution is to simply right multiply the primitive flux and source Jacobians by Gamma inverse, but this is not exact in the discrete setting. Thus, routines for calculating the flux and source Jacobians with respect to the conservative variables need to be added, and calc_res_jacob() needs to be updated accordingly.

Right now, the only non-solution field which can be plotted and probed is the species source term. This should be expanded to several other relevant fields, including the RHS, the residual, the unsteady heat release (per #35), and fluxes (which are not currently stored). This simply means adding conditional statements to grab these fields for plotting and probing.

Right now, trying to run an explicit Galerkin TF-Keras autoencoder ROM with a numerical (numerical_jacob = True) encoder Jacobian (encoder_jacob = True), an error gets thrown because I didn't implement it correctly. It may not be possible to generalize calc_numerical_model_jacobian() very well, since the number of dimensions for the encoder/decoder inputs and outputs are different, which makes slicing a challenge. Ultimately, this is low priority because the Galerkin ROMs kinda stink and the encoder Jacobian approximation makes it way worse.

Need to add an interface for low-intrusivity ROM stabilization, e.g. closure, artificial viscosity, filtering. When I say low-intrusivity, I just mean that the user doesn't have to touch the FOM solver routines. Ideally, this would mean that it only operates using the solution, residual, or RHS terms as they are calculated for a given subiteration.

For starters, I think the APG method, and one each of Traian Iliescu's ROM filtering and artificial viscosity methods would be good to implement to figure out a good modular framework.