Hi,
yes, this is possible and generally the metasteps are intended for this purpose. Some analysis types allow to do it other ways as well (for example in incremental linear analysis, you can change the load in each solution step). However, in nonlinear analysis this has to be done differently, as typically the previous load achieved has to be treated as fixed and the currently applied loading can scale accordint to load parameter, etc. And here the metasteps come into a game.
The metastep represent the sequence ot solution steps with the common attributes, like the same reference load vector. At the end of metastep, you can fix the achieved load level and continue new metastep with changed reference load vector, for example.
You can find the examples in tests/sm directory (Look for  control_switch_1.in and  control_switch_2.in files). And refer to metastep description in inputmanual.

Borek

Hi Giovanni,

in that case you have to combine two analyses. Perhaps easiest way is to adapt stagerred solver, which allows to combine different problems and assists in passing results and/or state  of one analysis to another one for subsequent analysis. This is typically used for thermal analysis followed by mechanical one, where computed temperature distribution is passed to mechanical analysis where it represents a load.  There some examples of these problems (see for example tests/tmsm/nltrans_incr.in and related nltrans_incr.in.tm and nltrans_incr.in.sm).
But this would require some modification of eigenvalue problem, as it should be able to take into account the state achieved by preceedenig analysis, but this is definitely doable and prototype examples exist.

Borek

It's not an insignificant amount of work, so I'm betting on "later". You can consider this to be on the TODO-list when it comes to new features, but there is little motivation for most developers to tackle this.

Thank you so much Mikael,
I really appreciate your effort, for me it's an important thing. Let me know if I can help you in any way, in the mean while I'll check out the actual code.

Hi Johnny. As I mentioned, there is currently no connection whatsoever between the different solvers.

The solvers completely switch, and we will need a way to map over the solution from one state to the next. Since the code doesn't exist, it isn't structured at all yet. But I can say that I want to keep clear separation between the solvers. Whatever vectors are stored in one solver shouldn't touch any of the potential vectors in the next. It should all be kept general, like a PrimaryField (which might just as well be predefined function).

The static structural solver shouldn't need to know what the next solver is. It should just offer the fields it has, and the next solver grabs whatever fields it needs, and stores them in whatever way it likes.