You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are several parameters that have to be manually checked and synced across solvers through their separate input decks. It would make sense to automate or add checks for these at the driver level. These would be a good extra ECP funds/relaxing Friday task for people to take on. A non-exhaustive but extensible list includes:
Timestep
Output intervals
Restart intervals
Initial conditions (vel, tke, sdr)
Max timestep
I think the best way to handle these is to have a syntax at the driver level that checks the parsed params, inputs for each solver before populating them. We can then either throw a warning, or update the values before initializing the solver objects in the code i.e. give the exawind-driver input file a higher precedent than the Nalu-Wind and AMR-Wind files.
The text was updated successfully, but these errors were encountered:
There are several parameters that have to be manually checked and synced across solvers through their separate input decks. It would make sense to automate or add checks for these at the driver level. These would be a good extra ECP funds/relaxing Friday task for people to take on. A non-exhaustive but extensible list includes:
I think the best way to handle these is to have a syntax at the driver level that checks the parsed params, inputs for each solver before populating them. We can then either throw a warning, or update the values before initializing the solver objects in the code i.e. give the exawind-driver input file a higher precedent than the Nalu-Wind and AMR-Wind files.
The text was updated successfully, but these errors were encountered: