The main application I have in mind is unsteady fluid-structure interaction
(fluids are first-order-in-time and solids are second-order-in-time). I
wanted to run by a few ways of I've been thinking about handling this for
discussion on the design (so apologies in advance is this is a little
unorganized) before I started writing code. This is mainly for folks using
FEMSystem-based applications, but, of course, anyone else is welcome to
chime in.
Currently, we have have a split between first-order-in-time and
second-order-in-time TimeSolvers. This made sense (at the time anyway),
since the needs were different between the different subclasses (e.g. we
need to track auxiliary velocity and acceleration vectors in the second
order case).
For the mixed case, there's a couple of ways we could go:
1. Convert second-order problems to first order problems and add velocity
variables to the System. I'd like to do this anyway at some point if for no
other reason just so we can try to play with DIRK schemes down the line for
this class of problems.
2. Treat the variables separately for schemes like Newmark or
Generalized-Alpha (the latter is what the Hughes disciples use in fluids,
solids, and FSI).
In either case, it seems like there should be a class at the same level as
FirstOrderUnsteadySolver and SecondOrderUnsteadySolver (called
MixedOrderUnsteadySolver?). There, the user would be required to set what
are first order variables and what are second order variables (and we can
sanity check that all time_evolving_vars() are set). Then, subclasses will
be able to do the right thing for the corresponding variables; in case 1,
velocity variables are added for second-order variables while in case 2, we
do appropriate updates on the first-order and second-order variables.
What bothers me about this is case 1. If we go this route, then, in theory,
we should be able to blanket reuse the _general_residual methods for any of
the FirstOrderUnsteadySolver subclasses. But, going through this design,
we'd have either duplicate that code as subclasses of this
MixedOrderUnsteadySolver, or somehow factor out the implementations of the
first order solvers so we can reuse those implementations.
This made me wonder if maybe we shouldn't rethink the design of the
TimeSolver hierarchy. Do we instead want to try and merge the FirstOrder
and SecondOrder into a single class and start tracking first order and
second order variables at that level?
Or add the concept of second order variables in the
FirstOrderUnsteadySolver and first order variables in
SecondOrderUnsteadySolver? Actually, that might work. We could maintain
backward compatibility with the current behavior and then check for the
"other" variables and do the right thing if someone "added" them to the
TimeSolver. Otherwise, the variables are treated in the default fashion
(depending on whether it's a first order or second order solver). Actually,
I think this might be the best way. This just occurred to me as I was
writing this, though, so maybe I missed something.
Thoughts anyone? Thanks for the time.
Best,
Paul
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
