[ModelPart inputs] Confusion on order when using in-memory ModelParts (esp. in Convection Diffusion)

[takeshimg92]

Description
In a standard Kratos pipeline, we start from a pre-constructed MDPA file, specified in the project parameters. All variables and degrees of freedom are added during the Initialize step of an AnalysisStage, specifically ImportModelPart, PrepareModelPart and AddDofs.

In my application, I want to (1) avoid MDPA I/O and (2) have flexibility to add new solution step nodal variables. Hence, I construct the ModelPart in memory. My understanding was that, as long as my order of operations was

0. Ensure "input_type": "use_input_model_part" in my project parameters
1. Create Model
2. Create ModelPart
3. Add solution step variables
4. Add geometry (nodes, elements, conditions etc)
5. Pass the resulting Model object to my AnalysisStage derived class

then everything would work. Indeed, this works well for StructuralMechanics but I am struggling with ConvectionDiffusion.

There, I have to essentially copy the code in the ConvectionDiffusionSolver, including AddVariables, AddDofs and I still cannot get it to emulate the correct behavior from when it just reads from an external MDPA. I am worried that I will essentially have to duplicate the ConvectionDiffusionSolver in order to process my ModelPart, which doesn't seem to make sense.

Is there something I am not seeing about how to best manipulate an in-memory ModelPart?

Scope
ConvectionDiffusion application

[matekelemen]

What exactly is the difference between the case with a read MDPA and your on-the-fly generated ModelPart? The order you wrote should be correct.

If you find yourself copying a lot of stuff from the ConvectionDiffusionSolver, it might pay off to derive from it rather than the PythonSolver base. If that's not possible or doesn't help you, we might need a bit more info on your specific application (or a small but complete example).