Error in writing watch-point for received mesh

Hi everyone,

I try to print a watch-point, but if I use the nearest projection or nearest-neighbor mapping, the file is printed with errors (file is attached). However, I observed that if I print two points, the second is correct. Did you observe this problem too?
precice-FASTEST-watchpoint-FinalPoint.log (40.6 KB)

Hi @JessicaMarino

By error, you mean the weird line breaks in the file? Or sth else?
This I have not seen before, looks like a bug.
Could you please upload the config where you get this problem and the config with the two points where the second one then is good?
Thanks!

Benjamin

Hi Benjamin,

I refer to the weird line breaks in the file “FinalPoint”. Also, I had another problem, I want to print three watchpoints in different points of a vertical flap. However, the second and third points are in the same position that the first point. I upload these files too.
Thank you in advance for your help.

This link is to download the files:

https://drive.google.com/open?id=1-wtoG7CjSDByOtHXfyNUwjV3xnPuesoX

Jessica

There are a few quite weird things going on.

  • the line break in “FinalPoint”
  • in all watchpoints the x and y coordinates are swapped
  • all watchpoints map to the same coordinate

To find out where the bug is (it is a bug) could you please help by testing two things:

  • Could you please move all watchpoints to the other participant Calculix and upload those?
  • Without doing that could you please switch on debug output in
<log>
    <sink type="stream" output="stdout"  filter= "(%Severity% > debug and %Rank% = 0) or (%Severity% >= trace and %Module% contains WatchPoint)" enabled="true" />	
</log> 

and upload your output.

Thanks!

Hi Benjamin,

These are the files for the watchpoints for calculix and fastest:

https://drive.google.com/open?id=1XafCbxrTJ1kgch1_u7sNZrtNU8hC0A-R
https://drive.google.com/open?id=1nUBReNBVI74rDUP0lbVPG-imGMaAp0I-

I am still quite puzzled what goes wrong.

On the CalculiX side (so in serial), the x and y coordinates are still swapped and the x coordinate is always mapped on the same value, 0.09. What is the mesh width at the coupling interface in your solid mesh? Could you also please upload the mesh export on the CalculiX side? You already have it your config:

<export:vtk every-n-time-windows="200" directory="vtk_calc"/>

One timestep is enough. You can directly upload it to Discourse as well.

Btw, your coupling convergence is quite bad. Try to increase the accuracy in FASTEST and/or CalculiX or decrease the strictness of the convergence measure in preCICE. Afterwards, you could tune the QN:

<max-used-iterations value="50"/>
<time-windows-reused value="10"/>

I reviewed my problem again, the problem with the “swapped coordinates” was my error because I mistyped the coordinates in the precice_config.xml file. I fixed this error, and now these coordinates look good.
However, the first watchpoint file is still weird. I re-attached the files of the watchpoints.

https://drive.google.com/open?id=1Ae7ht30kUSXZUmLaz2t8YzuACpbDFHY3

I am using a beam element (B32) of width 0.002, length 0.004, and hight 0.09 m of rubber. I have also uploaded the files of the solid grid (Calculix/beam32) and the vtk_calc files. Besides, I notice in the vtk-files that for the last point of the beam the exported value is very small, and not physical. Can you give me some ideas on why this happens?

I have increased the accuracy in FASTEST to less than 1e-6 normalize error, and I used the parameters “50, and 10” that you suggested, but the simulation is not stable. Divergence occurs when water wets the structure.
Do you have any suggestions about these types of cases when the load changes abruptly?

Hi @JessicaMarino

Sry for the late reply!
I try to summarize:

  • The swapping of coordinates was false alarm and so was the “identical mapping for all watchpoints”. All these things look good now in your last upload.
  • We still have the problem with the weird line breaks. This was not observable when moving the watchpoints to CalculiX, so to the provided mesh. After discussing this with @fsimonis, we decided to enforce this, meaning to allow watchpoints only for provided meshes. For received meshes, actually, we believe that we might get arbitrary behavior since we can have overlaps. And if a watchpoint then maps into such an overlap, we get some sort of race condition. If you still want to output the watchpoint on FASTEST side, you can also just use the information on the FASTEST meshes. Thanks for reporting this!
  • The stability issue you describe is an unrelated different problem. I will move this to another thread and answer there.
  • The “the last point of the beam the exported value is very small, and not physical”, I cannot follow. Is this the same as How can I create a Solid mesh for working with the nearest neighbor mapping? ? If not could you please open another post and give more information (screenshot) ? Thanks!

@JessicaMarino Thank you for reporting the problem!

Allowing watchpoints for a received mesh should never have been allowed in the first place and we are integrating an error message to prevent this during configuration.

The changes of PR 763 should be part of the next release.
preCICE will then stop with the following message:

ERROR: Participant "FASTEST" defines watchpoint "FinalPoint" for the received mesh "Structure_Mesh", which is not allowed. Please move the watchpoint definition to the participant providing mesh "Structure_Mesh".