Abaqus: use of surfaceid's and its order

[nicolasdlss]

Currently the JSON-file for Abaqus requires a list called surfaceIDs. This list should contains strings referring to the nodesets (as defined in the .inp file) corresponding to the surfaces with fixed names MOVINGSURFACE, where is 0, 1, etc. This list must have the same order as these surfaces.
This seems rather complicated especially for a new user. It is explained in the documentation, nonetheless it still took me a few reads to really grasp what is required.

Ideally, this would no longer be needed and surfaceIDs could even be removed.
However, it is currently used to link the name of the surfaces to the file to/ from which data should be written/read: e.g. CSM_Time1Surface0Output.dat.

Changing it requires a modification to USRInit.f and USR.f. It's the same code that has to be changed, where the integer following MOVINGSURFACE is detected to know what the file where the load points are stored (USRInit.f) or loads are read from (USR.f) is called. It occurs twice in each USR file.

See for example:

coconut/coupling_components/solver_wrappers/abaqus/USR.f

Lines 327 to 329 in 9778cb7

	R = INDEX(SNAME,'SURFACE')
	READ(SNAME((R+7):LEN(TRIM(SNAME))),'(I)') R
	R = R+1

Here SNAME is provided by the DLOAD or UTRACLOAD subroutine and corresponds to the name of the surface in Abaqus itself. Currently this has to be MOVINGSURFACE and is determined with this code.

It could be opted for to substitute a list of names of surfaces, as is now done in GetOutput.cpp and use that list to match the SNAME and as such determine the file to be read. The names could be inferred from the interfaces, and as such the surfaceIDs parameter could be completely omitted. As such the order will not matter anymore (as long as it's the same as for the other solver-wrapper).

We could even change the filenames of the .dat files (containing load points, loads, output nodes, displacements) not to contain the integer anymore but the name of the ModelPart instead. Or put them in directories named like these ModelParts. But that's more on a higher level of design choices for the code, as we ideally do something similar for each solver wrapper.

[hdolfen]

Another reason to change this behavior is because a mistake results in a very unclear error from the user-subroutine, for example:
forrtl: severe (64): input conversion error, unit -5, file Internal Formatted Read when trying to run the standard process on the usrInit.f job. The reason is in the lines of code below:

coconut/coupling_components/solver_wrappers/abaqus/USR.f

Lines 327 to 329 in 9778cb7

	R = INDEX(SNAME,'SURFACE')
	READ(SNAME((R+7):LEN(TRIM(SNAME))),'(I)') R
	R = R+1

If the USR fails to detect the word 'surface', it will read the wrong character, which will translate to a wrong number for R.
R is later used for the 'unit' of the file to be written, which in Abaqus/Standard is advised to be larger than 100. When R is wrong, it can result in a prohibited unit, resulting in the error above.