[MPM] Output process for tracking material point element/condition

[ncrescenzio]

📝 Description

This PR introduces two new output processes (MPMPointOuputProcess and MPMMultiplePointsOutputProcess)) which enable writing data stored in material point (element/condition) variables to file. This feature thus allows users to monitor the evolution of specific material points during the simulation.

The user provides:

• The coordinates of one or multiple target points
• A search tolerance
• The desired output time interval
• The material point variables to be printed

For each specified point, the process:

• Uses the new C++ utility BruteForceMaterialPointLocator to search for the material point closest to the given coordinates.
• Ensures the located material point lies within the user-defined tolerance.
• Writes the selected material point variable values to file at the requested time intervals.

---

🆕 Changelog

• New c++ utility BruteForceMaterialPointLocator for finding the material point element/condition closest to a given point by a specified tolerance value.
  • c++ unit test for the new utilitty in test_material_point_locator.cpp
  • python unit test for the new utility in test_material_point_locator.py
  • benchmark (based on google benchmarks) added in Kratos/applications/MPMApplication/benchmarks/brute_force_material_point_locator_benchmark.cpp
• Python output processes:
  • MPMPointOuputProcess: output process for writing data from a material point to a file.
  • MPMMultiplePointsOutputProcess: output process for writing data from several material points to different files.
  • python test in test_mpm_point_output_process.py
• Documentation for the python processes added in Kratos/docs/pages/Applications/MPM_Application/Output_Processes

[andimkatili]

Thanks for your work Nicolo!

I just have two minor comments (I think..)

[andimkatili]

Hi Nicolo. As always, thanks for your work!

I tried to use it and have one comment on the behavior. Currently, if an MP that is under the search tolerance is not found, it will print a warning and continue the simulation as normal. Personally, I would rather to have the process throw an error and stop the simulation, with the same reason why we decide to stop the simulation when the user provided unsuitable number of MP for the generation.

Running an entire simulation and realizing that the MP output is not printed wouldn't be a nice surprise after waiting for it to complete.

I'm not so knowledgeable about the parallelization (especially the MPMMinDistanceReduction), so I can't comment anything about it

Other than that, it looks good!

[ncrescenzio]

Done!