proteus
proteus copied to clipboard
erdc
Refactor TwoPhaseFlow App
- [ ] rewrite parun as pro using argparse
- [ ] replace app option as subcommand and move over app-specific options to subcommand
- [ ] split off some phases as subcommands (e.g. mesh)
- [x] move _p,_n,_so modules into single file using p/n/so object-based approach
- [x] move petsc options files into same single python file and set through petsc4py
- [ ] create subdirectory for apps
- [ ] refactor or remove fastarchive option if not needed
- [ ] move static docs into doc directory
- [x] move examples into tests and enable travis on them--don't want any untested code in the repo
Sorry for the stuff about fast archiving. I was having some troubles when outputting big files here at Kaust so I introduced that to speed up the process but I was not intending to get that into master. And, by the way, it didn't help much.
No problem. Good to know the story behind it. The archiving needs a good cleaning soon, so I'd be interested it any performance information. We could probably add some options to selectively disable archiving for some fields.
@tridelat and @manuel-quezada here is a simple example of object-based physics and numerics in a single-file problem description: https://github.com/erdc/proteus/blob/master/proteus/tests/periodic/duct.py
The basic idea is to just walk through the needed models setting up a default object and then overriding the options, then set up the global system parameters. e.g.
from proteus.defaults import (Physics_base, Numerics_base)
# Navier-Stokes physics
nse_p = Physics_base()
nse_p.LevelModel = RANS3PF.LevelModel.
...
# Navier-Stokes numerics
nse_n = Numerics_base()
nse_n = LinearSolver.KSP_Petsc4py
...
# CLSVOF physics
clsvof_p = Physics_base()
...
# CLSVOF_numerics
clsvof_n = Numerics_base()
...
# global system
from proteus.default_so import *
pnList=[(nse_p, nse_n),
(clsvof_p, clsvof_n)]
...
This avoids the necessity of doing from proteus.default_p import *, etc. and the dangers that involves due to the fact that Python modules are singleton. I would like to get rid of that last from proteus.default_so import *, but I have thought through the best way to do that yet. We could just have parun check for the existence of a single so object that could be initialized in the same manner.
It's not clear to me what the goal for TwoPhaseFlow is. With it's current capabilities, it looks like it's the interface which most users should be building cases in Proteus since it can handle domain generation, mesh generation, and analysis specification in a single file.
The initialization function of TwoPhaseFlowProblem assumes that the user is using some combination of a flow model and interface tracking models. Should it be allowed to handle single phase problems or should that be some other app like OnePhaseFlowProblem? As of now, it isn't very clean in terms of adding additional models like body dynamics.
For example, in the 2D floating body example, there's a need to specify the indices of the models: https://github.com/erdc/proteus_tutorial/blob/master/2d/floating2D_chrono.py#L228-L233
In the dambreak case, there's no need to specify those indices because they're automatically defined via TwoPhaseFlow:
https://github.com/erdc/proteus_tutorial/blob/master/2d/dambreak.py
On a separate note, I think the initialization function can be condensed from
def __init__(self,
ns_model=0, #0: rans2p, 1: rans3p
ls_model=1, #0: vof+ncls+rdls+mcorr, 1: clsvof
nd=2,
# TIME STEPPING #
cfl=0.33,
outputStepping=None,
# DOMAIN AND MESH #
structured=False,
he=None,
nnx=None,
nny=None,
nnz=None,
domain=None,
triangleFlag=0,
# INITIAL CONDITIONS #
initialConditions=None,
# BOUNDARY CONDITIONS #
boundaryConditions=None,
# AUXILIARY VARIABLES #
auxVariables=None,
# OTHERS #
useSuperlu=True,
fastArchive=False)
to
def __init__(self,
domain = domain,
models = modelList,
other = otherOptions)
The boundary and initial conditions need to be attached to their respective models within Proteus anyway, so it's better to just have the user be directly responsible for adding it in after the TwoPhaseFlowProblem instantiation. Several of the other flags such as nd and he can be attributes of the domain object.
The modelList could be a user-defined list of model objects that defines the ordering of the staggered solve and allows users to easily incorporate body dynamics or any other model. To avoid new-user confusion, we could define a default_modelList = [rans2p_model,vof_model,ls_model,rd_model,mc_model].
My understanding is that https://github.com/erdc/proteus/blob/master/proteus/TwoPhaseFlow/utils/petsc.options.asm is not a needed file anymore because of
https://github.com/erdc/proteus/blob/master/proteus/TwoPhaseFlow/utils/Parameters.py#L1483
from PR #954