Closed jfkiviaho closed 1 year ago
Yeah, there is some overlap in providing data from the model class to the SolverInterface
class, with the FUNtoFEMmodel
in the constructor and the Scenario
and Body
classes through the initialize
, iterate
, methods, etc. Also, a better name for the initialize
method would probably be initialize_forward
as it is the forward analysis version of initialize_adjoint
.
Many of the objects in FUNtoFEM need the model in the constructor including all of the SolverInterface
classes (as of yet). The Fun3dInterface
, for example, needs to know each of the bodies during its construction since it reads in the aero mesh through FUN3D and stores the coordinates in each Body
. On the other hand, the TacsSteadyInterface
needs the model in the constructor so that it can initialize the ScenarioData
metadata class for each Scenario
, holding adjoints, functions, and TACS states. Finally, the FUNtoFEMnlbgs
driver needs the model so that it can loop over each scenario calling the appropriate analyses from each solver, and telling it which bodies to include in the analysis.
I'm going to close this issue if that's ok. I gave it the question label so people can search for it later under the question labels section. I have another issue that I intend for people to see in the future after it is closed as well. I wonder what is the best way to ensure that.
Hi,
I've been working on a new solver interface for FUNtoFEM, and I was a little bit confused about ownership and use of the
Model
object in theSolverInterface
andFUNtoFEMDriver
classes.As I understand it now, a
SolverInterface
must have access to theModel
object in its constructor. This is so that it can, for example, callinitialize_aero_nodes
for a givenBody
object in theModel
and thus set the sizes of the data structures in thatBody
object before the driver callsinitialize_variables
on thatBody
object and creates those data structures. Otherwise, you end up with data structures of the default size zero, which isn't very helpful.But that fact---that a
SolverInterface
must have access to theModel
in its constructor---wasn't obvious to me at first. There isn't amodel
parameter in the constructor for theSolverInterface
base class. And most of the member functions that make up the interface of theSolverInterface
class, functions likeinitialize
, include parametersscenario
andbodies
. That gave me the first impression thatSolverInterface
doesn't need its own "reference" to theModel
, because the driver will just pass in theScenario
object orBody
list from its own "reference" to theModel
. And indeed that is how things work for the most part. Returning to the example ofinitialize
, the driver calls_initialize_forward(scenario, self.model.bodies)
which propagates theBody
list fromself.model
, the driver's own "reference" to theModel
, through toSolverInterface.initialize
via thebodies
parameter.So my conclusion is that
SolverInterface
doesn't actually need its own access toModel
for the most part, except crucially in its constructor when it needs to initialize the nodes in theModel
'sBody
objects. That's a little confusing. But I understand it could be difficult to disentangle. I don't really have any prescriptions. But I thought it might be useful to log this in Issues in case anyone finds themselves similarly confused in the future.--Jan