Communication problem of ls-dyna with dummy

Using preCICE
1

Hi I’m currently designing the precice ls-dyna adapter and am running into problems with communicating between this other solvers. I’m working on a cluster with CentOS 6 and ls-dyna is written in fortran77.

I ran it with a solverdummy and they know that they exist, and get to exchanging the data, but neither writing or reading work. The c++ dummy only reads 0 and the ls-dyna solver readData doesn’t change at all. Where could the problem be in this case and how do I debug it properly? The error messages only show that everything went as expected as long as you don’t print out the values of the Data as far as I can tell.

I also ran the fortran solverdummy with the c++ one and between those, there is no problem.

1 Like
2

Hi!

Could you upload the log files/output of the solvers as well as the preCICE configuration?

Currently, I could see the following issues:

  • Maybe there is something wrong in the preCICE configuration. There exists also a configuration vizualizer that can help checking the configuration.
  • Is the ls-dyna part validated? Are you sure that your ls-dyna solver writes data data to preCICE? Maybe an array with zero data is accidentally given to preCICE.
  • How many coupling iterations do you check? It can happen that there will be zero values exchanged in the beginning. This depends on the coupling/acceleration method and also on whether the coupling data gets initialized or not.
  • Do you call preCICE correctly from ls-dyna (advance, whileCouplingIsOngoing etc.)?
3
  • The configuration is not much modified from the normal solverdummy case
  • I don’t how I can validate the lsdyna part more. It already is able to call precice functions such as get_dims correctly.
  • This is the case for all iterations, I hardcoded it here so that ls-dyna always trys to write a specific number (here 10)
  • I’m decently sure that I do, its set up as in the step by step guide from the preCICE website.

cpp-solver-dummy-output.txt (4.0 KB)
ls-dyna-solver-output.txt (16.7 KB)
precice-config.xml (2.0 KB)

4

What you could to is

  • Enable more logging: Logging configuration | preCICE - The Coupling Library
    • Depending on verbose the output should be you need preCICE to be compiled with Debug flags. (Which I see you have already.)
  • You could check the data via VTK files: XML reference | preCICE - The Coupling Library
    • However, I am not sure what data is written in the VTK files (before/after data transfer). I did not find much documentation, but there has been more information on that here on discourse
  • What I could see being wrong (happened to me some times) that the data or mesh id on reading/writing has been wrong somewhere or the wrong name is passed in the ls-dyna code. I am not sure if you would be willing to share the code so one can have a look.
1 Like
5

Thank you I will try the steps you provided, when I can’t find anything I will copy the function calls and put them here. They are within the ls-dyna code and thereby under copyright so I can’t share everything.

1 Like
6

Hi again,
My debugging was sadly not really successful. The vtk files show, that the problem lies within ls-dyna, the data ls-dyna is supposed to write doesn’t appear within preCICE and the data from the dummy is not read by ls-dyna. But I basically copied the preCICE commands from the fortran solverdummy so I don’t know where the problem might lie. You can find the code below, I hope its somewhat readable.
Just to be sure, can this be a problem with compiling? Meaning that ls-dyna is not able to communicate because mpi doesn’t work properly or that the fortran bindings don’t work with fortran77?

More thorough precice output:
precice-debug.log (168.6 KB)
Code within ls-dyna:
ls-dyna-code.txt (7.8 KB)
One of the vtk files:
MeshOne-SolverOne.dt1.txt (885 Bytes)

7

Hi,

in line 63 you should replace reatItCheckp by readItCheckp. I am not sure whether that has any influence though.

In you logfile I also see the following statements:

(0) 15:20:58 [impl::SolverInterfaceImpl]:1176 in readBlockVectorData: e[0mEntering readBlockVectorData
  0: dataID == 1
  1: size == 0

and

(0) 15:20:58 [impl::SolverInterfaceImpl]:1048 in writeBlockVectorData: e[0mEntering writeBlockVectorData
  0: dataID == 0
  1: size == 0

It seems like you want to write data, but you write data with size 0?! I assume that you call your module once per time step from some other function. Could you try adding

integer numberOfVertices

somewhere in the variable definitions around line 15 to 22? At the moment numberOfVertices only gets a value set as a local variable in line 57, but it then zero after the initialization. However, it does not complain about this as variables starting with i,j,m,n… (probrably some others) are automatically declared as integer in Fortran. You can find this variable also in variable declaration of the dummy solver.

Edit: I might be wrong about whether you have to declare this variable or not, but I would definitely check numberOfVertices. The size should not be zero. At the moment you tell preCICE to read and write zero data points.

1 Like
8

Thank you a lot, declaring integer numberOfVertices in the common_data module fixed it and it works now like the solverdummy should!

9

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.