GPLaSDI icon indicating copy to clipboard operation
GPLaSDI copied to clipboard

Restart capability and offline FOM interface

Open dreamer2368 opened this issue 5 months ago • 0 comments

Restart capability

The workflow now supports restart capability, saving/loading necessary data to/from a restart file.

  • Following classes support export and load function, which saves/loads from a dictionary:
    • Autoencoder
    • ParameterSpace
    • LatentDynamics, SINDy
    • Physics, Burgers1D
    • BayesianGLaSDI
    • Timer
  • lasdi.workflow.main function saves/loads all these classes into/from a restart file.

Interface to offline FOM simulations

For greedy sampling, new FOM solutions are added to the training data. For offline FOM simulations, the python training needs to be paused, so that FOM simulation runs for new parameter points and saves the solution ready to read from python framework. This is now supported by two workflow stages NextStep.RunSamples and NextStep.CollectSamples.

  • lasdi.workflow.run_samples
    • if FOM is built in python framework, it runs FOM simulation without pausing python framework
    • If FOM is offline solver, then it rather saves the new parameter points in a hdf5 file which FOM solver may read for simulation.
    • It saves parameter points for training data and test data separately.
    • The parameter point file names are specified in yaml input file as:
      • ['workflow']['offline_greedy_sampling']['train_param_file']
      • ['workflow']['offline_greedy_sampling']['test_param_file']
  • lasdi.workflow.collect_samples
    • if FOM is built-in python solver, this routine is not needed.
    • If FOM is offline solver, FOM will produce the solution (on an outside script) according to the parameter points saved from run_samples. collect_samples then reads the solution and appends training/test data.
      • The FOM solution file names are specified in yaml input file as:
      • ['workflow']['offline_greedy_sampling']['train_sol_file']
      • ['workflow']['offline_greedy_sampling']['test_sol_file']
  • For this interface, h5py package is used to use hdf5 format, which can be well accessed from most of programming languages (supposedly).

Offline FOM wrapper and offline driver for Burgers 1D equation

  • lasdi.physics.OfflineFOM provides a wrapper for offline FOM simulation. It does not solve/run any simulation, rather only specifies spatial/time grid size and solution dimension.
  • A separate executable burgers1d provides a offline, command-line driver for Burgers 1D equation. It reads input options from a yaml file. In essence, it provides the offline FOM part that connects to the interface described above.

Factorizing training and greedy sampling stages

  • Previously, BayesianGLaSDI.train performs both training and greedy sampling. This is now separated into train and get_new_sample_point.
  • lasdi.workflow.pick_samples runs BayesianGLaSDI.get_new_sample_point and append the parameter training space.
  • These two stages are run as separate stages NextStep.Train and NextStep.PickSamples.

Prerequisites addition

h5py package is required for saving/loading parameters and FOM solutions.

Full workflow demonstration of Burgers 1d example

  • examples/burgers1d.ipynb now also include data generation/training stages, as well as post processing.
  • examples/burgers1d.offline.bash also demonstrates the entire workflow with offline FOM solver.

Variable name changes in BayesianGLaSDI class

  • n_iter -> max_iter: maximum iteration for the entire workflow
  • n_greedy -> n_iter: number of iteration for one train routine. This is also the frequency of greedy sampling.
  • max_greedy_iter remains the same.

dreamer2368 avatar Sep 12 '24 01:09 dreamer2368