xbeam/sharpy load ramping in nonlinearstatic solver

[kccwing]

To be reviewed in conjunction with related xbeam pull request here. Changes below require related pull request on xbeam to be merged before it will compile without issues.

sharpy/solvers/nonlinearstatic.py -> added support for load ramping via optional flag ['load_ramping'] = 'bool' to maintain backwards compatibility, additional output-only parameter ['load_ramping_conv'] = 'bool' to receive convergence information from xbeam fortran scripts.

sharpy/routines/static.py -> added optional parameter l_ramp for load ramping

sharpy/structure/utils/xbeamlib.py -> added relevant support for ramping information passing to/from xbeam fortran scripts

tests/xbeam/generate_minguet_loadramping.py -> test case for load ramping functionality (load ramping required once in minguet_c450_4)

tests/xbeam/job, tests/xbeam/job.o5486816, tests/xbeam/job.e5486816 -> job file for the Imperial HPC system, and the runtime output/error log

tests/xbeam/Generate_plots.ipynb -> to visualise the output of generate_minguet_loadramping.py

[ngoiz]

Many thanks Kelvin,

This will be a nice feature for the code, but at a first glance, a few changes I think are needed:

• Split the PR into multiple PRs with the new features. It looks like @ACea15's model generator and routines features are (partly or fully) included in this PR. If these are required for the load ramping features, I would first merge those separately if they are production ready and then do this one. If those features are not required for the load ramping or not ready to be included, simply remove them from these changes.
• A few files include import importlib and reload module, which I assume was used during development. I would remove these from the main code.
• I guess this is part of the models generator, but a few matrices/eigenvalues files are stored. Unless needed for an example I would remove. Also, spelling in the folder wing_plantformo/.
• The HPC job file. Is this something that goes with the code or a script for a specific case? If the latter, it would be better suited in the scripts file. If the former, is it a test that should run with unittest?
• Until the corresponding changes in xbeam changes for sharpy branch dev_xbeam_ramp xbeam#10 are merged onto the master branch, please update the submodules in this branch to use the correct one.
• Update with develop to have the latest changes (and, most important, the fixed unittest)

Hope this helps! Once the PRs are split I will have a more thorough review.

Thanks,
Norberto

[ACea15]

Thanks Norberto, that's absolutely right. There is two main features on this pull: 1) the solution of a highly nonlinear structural problem with composite materials, which had not been tested before and therefore will be added as a new test; 2) the feature for load-ramping in the structural static solver, which was actually needed to solve 1).

In terms of merging we should do the add pip support first, then the (CLEAN) generators that are used to build 1), and finally this branch.

The jobs to the HPC should be removed and the .ipynb added as a demonstration in the example_notebooks, thus keeping in the test folder just the files for unittesting.

[kccwing]

Hi @ngoiz @ACea15,

Thank you so much for the comments! They are absolutely on point.

Model generators/ routines are not required for the feature, but is utilised in the test case to run the structure with various loads to confirm a nonlinear trend.

Hence I could pull a (high) load case from the script and rewrite into a simple unittest by confirming just the deflections at that point, potentially bypassing the model generator and routines that way, or we could wait until those are merged then perhaps use this as a test for those too.

Will incorporate the comments regarding housekeeping once we have a decision. Thank you very much again!