Topic: Looking for permission to push ahead with some bigger changes

Hi everyone. I have had a bit of a break from OOFEM, but I have been planning on getting back into it very soon.

But! I have had a number of changes that I have wanted to deploy, which I have held back on for a very long time now, because they do change behavior, or removes a means to use the code in a particular way.

The single most important feature, is that of the way we handle dofs, bc's, and IC's, in code, as was discussed here: http://www.oofem.org/forum/viewtopic.php?id=1662 (wow, it was back in 2016)
This is critical for FE^2 simulations, and will, overall, mean much more features in almost all solvers, and way less code.

A common blocker has also been the way nlinearstatic handles mixed input control. I have an alternative approach, but, I have intentionally not made it 100% compatible. The DOF changes will, unavoidably, break nlinearstatic, and there is no way to do it the old way anymore.
But, IMHO, the old way is a dead end. The new approach, marking the *load* as direct or indirect, is much more natural, easier for users, allows for single-step anlysis (so potentially twice as fast in common scenarios).

A whole bunch of relatively minor improvements, that aren't complicated, and can be done in next to no time at all if we agree to go ahead:

Re: Looking for permission to push ahead with some bigger changes

I want to remove "nonstationaryproblem" and "nltransienttransport". Both of these have been replaced by the more general, simpler, and more correct, transienttransport.
We must remove these because they inherit from "stationarytransport" (which is quite backwards) and prevents stationarytransport from implementing necessary changes to DOF-handling.

3

Re: Looking for permission to push ahead with some bigger changes

Hi Mikael,
nice to have you back again, go ahead, I think some changes have been discussed already (BC/IC), and others you mention sound great. Perhaps make the changes in a separate branch, so the changes could be discussed before the final merge into master.  We would also need some time to add support for some  features not present in staticstructural (adaptivity, for example).

Borek