Conversation
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
📝 Description
While adding planned features to the RomApplication, it became clear that
RomParameters.jsonis too rigid. The file controls too many things at once. It describes the trained ROM (basis, HROM weights, solver settings), and it also drives the workflow through flags (run_hrom,train_hrom,rom_manager) that theRomManagerrewrites before every stage. This makes the file hard to extend to coupled physics. It is also not ready for the functionality planned for the near future, such as local ROMs (as opposed to global ones) and other nonlinear ROM methods.This PR is the first step towards a standalone, composable description of a trained ROM (a "version 2" layout). No behaviour changes: files are still written in the current layout.
rom_parameters.py, is now the single owner of the format. Every Python read and write ofRomParameters.jsongoes through it.deployment: default deployment options, replacing the flags.components: one per solver, each with its `projecticoupling: an optional block for coupled solvers.hyper_reduction: the HROM data.manifold.type:global(a singledecoder) orlocal(aselectorplusclusters, each with its owndecoder).decoder.type:linearorann_enhancedtoday (the same values as theRomManager'stype_of_decoder). New nonlinearrbfare added as new decoder types.coupled_solvers) and [RomApp] HROM for ANN Enhanced ROMs #14785 (galerkin_ann/lspg_ann).Next steps (separate PRs):
RomManager.Note: the C++
HromVisualizationMeshModelerstill parsesRomParameters.jsondirectly. It must be updated before version 2🆕 Changelog - Added
rom_parameters.py: loader/writer for `RomParameversion between the current layout and the new version 2layout.RomParameters.jsonontorom_parameters.py:rom_analysis,RomManager._ChangeRomFlags,CalculateRomBasisOutputProcess,HRomTrainingUtilityality`.test_rom_parameters.pyto the small suite. It covers:localmanifolds and non-ANN nonlinear decoders, which cannot be written in the current layout.