This new test battery consists of a large number of simulation that are directly implemented in Gitlab: whenever a new push is made, the continuous integration pipeline launches a build phase and then a test phase. If everything went right, the merge is possible. Otherwise, the user is required to correct its mistake before being able to merge. This improves the robustness of the code and avoids mistakes.

Implemented by: Arthur Fanara, 2025

Gitlab's Continuous Integration (CI) is launched through the file .gitlab-ci.yml in which two steps are defined:

1. 1. A build phase that generates, in Unix, the Prepro.exe, Lagamine.exe and Select.exe. This gives a first information on the state of the code.
2. 2. A test phase that launches as many tests as implemented. It uses three .sh files:
   • run_tests.sh: this file cycles through the $CI_PROJECT/Tests/ folders in order to run each test. The prepro and lagamine is run for each test, then the .ipe, .ipn and .ipr are compared with the original results that may be found in a folder ExpectedResults. For the moment, the tolerance is set to 3% and any value below 1E-7 is rounded to 0.0.
   • run_prepro.sh: this file calls the newly generated prepro.exe for the test case.
   • run_lagamine.sh: this file calls the newly generated lagamine.exe for the test case. The .ipe, .ipn, .ipr, .log and .out are generated and exported in the artifacts of Gitlab, for further referencing. The simulations are run in sequential as all routines do not allow the use of parallelisation at the moment.

If one of the steps goes wrong, the job fails and the user is not allowed to merge its modification.

The folder 'Tests' contains all the tests.

Each test is in a separate subfolder named with the same name as the test defined in “Test_battery.txt”, preceded by its number. For example, 26_HYPOFE2_KFLU1 is the 26th test in the battery, and it verifies the integrity of the law HYPOFE2 with parameter KFLU1.

In this test subfolder, there are:

1. The necessary files to run the prepro and lagamine: .DAT, .LAG, .PRI, .DEP, .LIC, and so on.
2. A subfolder named “ExpectedResults” in which the results file are: the .ipn, .ipe and .ipr.

No other file should be found in this subfolder.

In order to ensure that your developments in the Lagamine code will keep functioning properly, it is highly recommanded that you add one or several tests specific to the law(s) or element(s) you use and develop.

To test a material law or an element, you should design a simple test, using only 1 element when possible. Preferably, your test should not take more than a few seconds to run. If you need to test something more complex, you can also create a “Big” test. However, the total number of Big tests should be limited to avoid excessive computational times for the whole test battery.

Once you have designed your test and created the necessary simulation files, you must identify the important variables that indicate whether your law/element is behaving as it should.
These values can be obtained via the *.ipe result file.

Be sure to print out the values you want to check at the time step(s) you see fit.
To define the time steps at which you want a printing, you can use ILSAV = 1 or 2 in the ex.dat file.
Check Appendix 1: Printing options and Appendix 9: Printing files for more info about printing files.

To add a new test to the battery, you should:

• Add the new test to “http://www.lagamine.uliege.be/dokuwiki/doku.php/battery/listtests”
• Add the folder containing your test to the test battery directory.