Point in ConstantPointSource is not found with MPI execution

[abqlalala]

Hello all, I am running solid mechanics simulations with point loads (using DiracKernels with type = ConstantPointSource). I have made sure the coordinates of the points match the coordinates of some nodes (as I would like to apply the point loads directly on those nodes). Below is an example of what I used for these point loads in my input file:

  [PointLoad1_y]
    type = ConstantPointSource
    point_not_found_behavior = WARNING
    variable = disp_y
    point = '192.903 29.9277 21.5488'
    value = -40.0179
  []

I realized that in some simulations MOOSE cannot locate points in the mesh and thus those points loads get ignored with the following warning message:

The following warning occurred in the DiracKernel 'PointLoad1_y' of type ConstantPointSource.
Point (x,y,z)=( 192.903,  29.9277,  21.5488) not found in block(s) 24, 25, 26, 27, 28, 29, 30. 

This problem only occurs during MPI execution, and during multi-threading execution I don't see such warning. I also tried to modify the coordinates of the point loads so they are located inside the volume mesh instead of right at the particular nodes, but the point still cannot be found.

Here are my questions:

1. what causes the missing point load only during MPI execution?
2. Is it just a warning given by the processor that does not have the node within its element partition? i.e., it is just a false alarm as the point load will be applied by the processor that owns the node?
3. If not, how can I make sure all points can be located during MPI execution?

Thanks for the help!

[abqlalala]

I tried setting use_displaced_mesh=true and allow_moving_sources=true, but the points still cannot be found.

[GiudGiud]

Hello

Is it just a warning given by the processor that does not have the node within its element partition? i.e., it is just a false alarm as the point load will be applied by the processor that owns the node?

Looking at the code it actually does look like a false alarm from a processor/process not owning the element.
But is the mesh distributed? Because if the mesh is replicated, all porocessors know about all elements

[GiudGiud]

Then this does not make sense why you would get the message.

Can you plwase make a shareable example reproducing the issue?

[abqlalala]

I am not able to share the current examples I have but I will look for something simpler. Thanks!

[abqlalala]

@GiudGiud I checked the reaction forces from the 'saved' variable in MPI simulation results, and every point load block in my input file can be located somewhere in the contour, i.e., I can find the corresponding nodes with saved_x, saved_y and saved_z values same as the point load values, though MOOSE still outputs the warning messages about missing point during MPI execution. Does that mean the point loads are actually applied during MPI execution? Or is the 'saved' variable just displaying whatever in the input file without applying the point loads?
Thanks!

Here are syntax I used for the AuxVariables:

[AuxVariables]
  [saved_x]
  []
  [saved_y]
  []
  [saved_z]
  []
[]
[Physics/SolidMechanics/QuasiStatic]
  [all]
    add_variables = true
    strain = SMALL
    generate_output = 'stress_xx stress_xy stress_xz stress_yy stress_zz stress_yz vonmises_stress'
    save_in = 'saved_x saved_y saved_z'
  []
[]

[Kavan-Khaledi]

Hi, I remember I had the same issue before. In my case, the warning from point_not_found_behavior = WARNING was misleading, and the DiracKernel was actually working correctly.
Did you try point_not_found_behavior = IGNORE to see if the DiracKernel works or not?

[abqlalala]

Thanks for the information!
As long as the point loads are applied correctly during MPI I am ok with warning messages.
With point_not_found_behavior = IGNORE, I don't see any warning message but I am still curious if the point loads are actually applied or simply get ignored silently. Is there a way to confirm that?

[Kavan-Khaledi]

Checking the save_in options is a good way to confirm wether the point load has been applied or not, which you have already done;)

[abqlalala]

Thanks again for the information!

[GiudGiud]

Thanks for reporting and thanks for pitching in!
I'll try to fix that so the warning can be trusted