First Brainstorming about the handling of multiple loadcases

[RiccardoRossi]

ok, this is a very first brainstorming about what is needed to mimic Nastran handling of load cases, spcs (fixity) and mpcs

here it is put on the top of the analysis stage, and is completely not standard ... the idea is simply to explain what is needed and we start discussing from here

    def Initialize():
        #form the dofset
        global_dof_set = ... 6 dofs  --> Ndofs
        
        R.shape = (ndof)
        K.shape = (ndof,ndof)
        
        assemble Kglobal
        
        for spc in spcs: #fixities - in nastran it contains the load cases
            fixity[spc.name] = ...
        
        for mpc in mpcs: 
            ...
            
        for load in base_loadcases:
            f = AssembleLoads....
            load_database[load.name] = f
            
        combined_loadcases = ...
        spc_groups = ...group together similar spcs and mpcs
            
    def InitializeSolutionStep(self):
        
        
            
        for load_combination in load_combinations:
            ...
            
            
            
            
    Kglobal dxglobal = Rglobal
    
    dxeff = T * dxglobal + q  #T and q take into account MPCs and SPCs
    
    Keff = T^t @Kglobal@ T
    Reff = T^t @ R
        

        
        
    def RunSolutionLoop(self):
        """This function executes the solution loop of the AnalysisStage
        It can be overridden by derived classes
        """
        for spc in spc_groups:
            T q 
            Keff
            Keff_factors
            for load in spc_loads[spc.name]:

                self.InitializeSolutionStep() Reff
                self._GetSolver().Predict()
                is_converged = self._GetSolver().SolveSolutionStep()
                self.__CheckIfSolveSolutionStepReturnsAValue(is_converged)
                self.FinalizeSolutionStep()
                self.OutputSolutionStep()
                
    def OutputSolutionStep():
        for out in outputs:
            ...

[T-Siemer]

Meeting Minute 21.10.2015

Nastran Syntax:

SUBCASE 1
SUBTITLE = LinearBuckling
SPC = 1
LOAD = 1

SUBCASE 2
SUBTITLE = StaticAnalysis
SPC = 1
LOAD = 2

SUBCASE 3
SUBTITLE = StaticAnalysis
SPC = 2
MPC = 1
LOAD = 2
.
.
.
Model definition (Nodes, Elements, Constraints, Forces/Moments, ...)
.
.
.

Definitions:

SPC: Single-Point Constraint (dof set to zero or enforced displacement)

• Reduces the global stiffness matrix of the model (if dof is fixed)
• In case of enforced displacement the reduction still occurs but the according stiffness components are multiplied by the enforced displacement and transferred to the right hand side

MPC: Multipoint Constraint

• Reduces the global stiffness matrix of the model (linked dofs are removed)

LOAD:

• Static load as a linear combination of load sets defined via FORCE, MOMENT, FORCE1, ...
• Load vector $P = S \sum_i S_i P_{L_i}$

For SUBCASE 1 and SUBCASE 2 the same SPCs are applied to the model. Thus, the reduced stiffness matrix is the same. For SUBCASE 3 the reduced stiffness matrix needs to be computed again.

[T-Siemer]

Nastran example:
linearbuckling.txt

[rubenzorrilla]

Here my two cents after an admittedly very short thinking:

1. IMO the application of T (i.e., getting the effective arrays) should be done at the strategy level. If one wants to keep K, this must be passed as a setting to the strategy. Note that this will automatically handle the nonlinearity of K.
2. Should we handle SPCs as single-DOF Kratos MPCs or map Nastran info to our standard fixity and let the Builder decide depending on the build type (block or elimination)?
3. About the loads, as far as I understand we need to create a tool that translates Nastran loads to create our conditions. We group these together in submodelparts to then set the active/inactive flag according to the loads case.
4. Should this be an orchestrator? I note that altough being a more natural approach IMO, it would most probably complicate keeping K sparse graph among load cases.

[sunethwarna]

Hi all,

My opinion on this:

1. This is a valuable feature for Kratos, and I am surprised this issue was created in the NastranCompatibilitySandBox, but not in Kratos. We and some of our industry collaborators also need it in specifically StructuralMechanicsApplication.
2. If we are considering this, then there should be a rule saying there cannot be any member variable use cases in Element or Condition or MPCs, since they can affect the solution indirectly by propagating remaining values in those member vars to next load case [Nightmare to debug these errors #13911].
3. If we are only considering the multiple load cases in a static linear case (to take advantage of the same K and re-use the factorizations of the linear solver), then we need processes applying different loads (force, moments), then this keep_factorization setting must be passed through to the linear solver level. The current possibilities for setting load cases are: - Proposal A - Use processes having different time intervals with different loads [ In my opinion, this is hackish - because then we need to have another process clearing out the previous load cases as well. ]
   - Proposal B - Use separate named blocks for processes at the JSON level to do multiple load cases [ Clean and straightforward, May be implemented as a separate analysis, does not have to be an Orchestrator] since this is anyway only valid for linear cases, since we want to use the same factorization.
4. If we are considering multiple load cases in a static non-linear analysis, transient linear analysis, or transient non-linear analysis -> then still Proposal B can be used. This can also support changes in the DBCs and MPCs, as it cannot take advantage of using the same K and its factorizations. [Even though this cannot take advantage of reusing the K, it still can take advantage of using the same read mesh, may be the sparsity pattern of the K, ...). And if we are considering this, then this would be a useful feature for all of the other applications (e.g., Fluid, Optimization) as well.
5. If we are to use the Orchestrator, we need to expose the Strategy in each AnalysisStage to set the keep_factorization flag. I think this may be overkill and does not suit at Ochestrator.

In my opinion, we need to finalize and agree on the type of multiple load cases we need to support, and then decide on the implementation approach. Anyway, I am putting my JSON proposal here as a starting point.

Proposal B.

• After using each load case, the data should be cleared, which means PythonSolver should have interfaces to clean data and/or reset data to the previous state as well as a way to save the current state for future use.
• After each load case, the processes of that load case are destroyed to recover memory [We never know how much memory each process may occupy]

Example Proposal B - 1 [Every load case has its own load cases and output processes also specified]

{
   "problem_data": {},
   "solver_settings": {}
   "load_cases": {
           "load_case_1": {
                 "processes": {
                       "constraints_process_list": [{}],
                       "loads_process_list": [{}],
                       "list_other_processes": [{}]
                 },
                 "output_processes": {}
           },
           "load_case_2": {
                 "processes": {
                       "constraints_process_list": [{}],
                       "loads_process_list": [{}],
                       "list_other_processes": [{}]
                 },
                 "output_processes": {}
           },
           "load_case_3": {
                 "@include_json": "load_case_3.json"
           }
    }
}

Example Proposal B - 2 [Every load case has its own load cases, but output processes are common. We can then have different output files by specifying the <load_case_name> flag in the file names, which will be read through the variable LOAD_CASE_NAME in ProcessInfo.

{
   "problem_data": {},
   "solver_settings": {}
   "processes": {
           "load_case_1": {
                  "constraints_process_list": [{}],
                  "loads_process_list": [{}],
                  "list_other_processes": [{}]
           },
           "load_case_2": {
                  "constraints_process_list": [{}],
                  "loads_process_list": [{}],
                  "list_other_processes": [{}]
           },
           "load_case_3": {
                 "@include_json": "load_case_3.json"
           }
    },
    "output_processes": {}
}

[sunethwarna]

After discussing with @RiccardoRossi , I now understand this is only about multiple load cases for linear problems. Therefore, I would like to add the following points:

So we have the following hierarchy (only components which are important for the point which I would like to make)

Ochestrator -> AnalysisStage -> PythonSolver -> SolutionStrategy -> LinearSolver

Now StructuralMechanicaAnalysisStage is supporting any type of solver (linear, non-linear, transient). Therefore the speciality of this discussion which is only talking about multiple load cases for linear structural problems indicates that it should not be implemented in Ochestraor or AnalysisStage, but it should be implemented in PythonSolver which knows about the problem being solved. I understand that there needs to be a few more interface functions from PythonSolver to achieve this, hence the exercise which @RiccardoRossi is carrying out is super important as well to understand what interfaces are additionally required to solve multiple load cases efficiently.

This again boils down to having clear responsibilities defined for AnalysisStage and PythonSolver which will be useful in this discussion as well in my opinion, so not to propagate unclear distinction of responsibilities.