# GSM Presentation Framework

The notebook #file:0902_gsm_ve.ipynb  shows a preliminary version of a scenario or workflow which presents the particular version of GSMDef class. The first part shows the symbolic representation of the potentials and of the residuum governing the material behavior. Then, a set of material parameters is defined in a dictionary which is used to configure the GSMModel(GSMDef) by using the set_params method. After that, a sequence of loading scenarios is constructed either directly or using the classes from the subpackage #file:time_fn.py. In this context, the chosen scenario depends on the covered methodology.

The goal of this presentation is to verify if the expected phenomenology is correctly represented by the models. 

1) For example, for viscous models, the stress and strain step loading and unloading are conducted. 

2) Another presenter can show the rate dependency of response upon monotonic strain-driven loading. In this context, the determination of the maximum stress sig_max provides an important characteristic for the definition of further loading scenarios. This reveals the iterative nature of the intended automated model presentation/verification framework. The loading scenario, the selection of the strain- or stress-control, which is linked to selection of the get_F_response, or get_G_response in the GSMModel instance represent the specification of the input data of the whole problem and that the instance of the ResponseData class is postprocessed in order to approach to the next step in the presentation/verification process.

3) This particular aspect - the chaining of the presentations and postprocessing steps - is included in the verification of the comparison between strain- and stress-controlled response in the ascending branch of the material behavior. This aspect may represent a kind of a unit test for any of the models - calculate the response using strain control up to the peak and then extract the ascending branch of the stress response including its time-dependency. When running the stress-controlled problem, i.e. the get_G_response the obtained strains must be identical to the linearly ascending controlled strain profile using in the previous step. This is particularly valuable for rate-dependent models.

4) Once the verification for monotonic loading has been, scenarios with cyclic response are to be conducted. In the definition of the loading scenarios, multiple aspects can be used to branch the presentation-verification steps. It is assumed that the strain-controlled monotonic response includes feilure, i.e. there is a peak stress. Another characteristic is the length of the postpeak branch. Characteristics defining this behavior tell us if it makes sense to run some low-cycle fatigue scenario showing the hysteretic loops. However, this scenario is of a lower relevance at the moment. 
Still, running a scenario with one unloading-reloading cycle in the prepeak regime and two cycles behind the peak might be helpful. For this type of verification, it should be known what is the strain at the onset of inelasticity and what is the strain ate peak.

5) Important scenario is the one defining the stress driven fatigue loading which is defined relatively to the peak stress as a fraction e.g. S_max = 0.9 and S_min = 0.1. For simplicity 

I would just assume the positive range  for the loading scenarios. Why I'm writing this is the question of a strategy how to implement and represent such scenarios. I can certainly start to define classes involved in the presentaiton/verification framework whic include the time-function, specification of the strain- or stress-type of loading, and then defining some postprocessors which would derive particular characteristic values of one presentation step which are needed for the next presentation/simulation step. But I have the impression, that there might be already some useful framework helping to represent these kinds of processes. As the individual simulation steps might become demanding later, the individual process nodes/steps should be persistent and have their data image within a file system or a database so that the process can be decomposed into transparent time-steps - with predictable execution time and with the possibility to inspect the interim state of the processes. Currently I am thinking only of a sequential process, however, already now, it is apparent that some branching might occur later on - with the goal to calibrate some material parameters through a comparison with experimental results that are targeted towards particular dissipative effects, e.g. relaxation test, creep test, cyclic test with ramps for relaxation..

I would appreciate if you can advice both concepts for devising such a framework both in the realm of formalisms at the conceptual level, e.g. UML-based design - I can imagine to iterate on such an architecture with a copilot which iteratively provides a PlantUML format of the framework. However, I do not want to reinvent a wheel and expect that this question has been already adressed by many others. I would be thankful for advices and hints both from the open-source ecosystems - preferable in Python. However a brief summary of UI-based systems would be appreciated as well. 

