Check f determinant

[Jasmine969]

This PR is a continuation of PR #1034 . In PR #1034 , @Xiangyu-Hu suggested that a separate method class should be added to monitor the physical behavior of a variable rather than if-else check in the computing kernel. I introduced unrelated commit histories by mistake there. In this PR, I implemented this feature with DeformationGradientDeterminantCheck in elastic_dynamics.*. This class checks whether each particle has a positive & finite determinant of the deformation gradient, and reduce this value with ReduceOR. If the reduced value is false, nothing will happen; else, a message will be printed on the screen showing which particle has invalid determinant, by std::cerr.

This dynamics will be called in BaseElasticIntegration::setupDynamics so that the positive definiteness will be checked automatically when elastic dynamics is used.

Also, I removed the assertions in polarRotation/Decomposition since they are invalid in the release mode, and the positive definteness has been ensured in BaseElasticIntegration::setupDynamics.

Hope this will be satisfactory.

[Xiangyu-Hu]

@Jasmine969 Thanks for the change. I think that it would be better not modify the library but write a new particle dynamics for the checking. Furthermore, as we have already ceased to the development of the old CPU code and I would not bother to change the old code, except a big bug. How about write the checking method in SYCL framework? It would be much more useful.
My suggestion is to write a class called QuantityCheck like the class QuantityReduce in
https://github.com/Xiangyu-Hu/SPHinXsys/blob/master/src/shared/shared_ck/particle_dynamics/general_dynamics/general_reduce_ck.h
The design idea is, according to the input variable name, register a new int variable named variable_name + "Check", and a template class for checking condition, after run the method, the code tags all particles does not satisfying a condition (with 1) and return false if at least one particle does not satisfy the condition. One can also let the code stop the simulation and output to show where are the particles do not satisfy the condition (in FinishingDynamics).

[Jasmine969]

@Jasmine969 Thanks for the change. I think that it would be better not modify the library but write a new particle dynamics for the checking. Furthermore, as we have already ceased to the development of the old CPU code and I would not bother to change the old code, except a big bug. How about write the checking method in SYCL framework? It would be much more useful. My suggestion is to write a class called QuantityCheck like the class QuantityReduce in https://github.com/Xiangyu-Hu/SPHinXsys/blob/master/src/shared/shared_ck/particle_dynamics/general_dynamics/general_reduce_ck.h The design idea is, according to the input variable name, register a new int variable named variable_name + "Check", and a template class for checking condition, after run the method, the code tags all particles does not satisfying a condition (with 1) and return false if at least one particle does not satisfy the condition. One can also let the code stop the simulation and output to show where are the particles do not satisfy the condition (in FinishingDynamics).

Good idea. But I have not used the SYCL version. I could not install it successfully locally. Someone else may be more suitable for its implementation.

[Jasmine969]

we have already ceased to the development of the old CPU code

Does it mean that no features will be added to CPU code? Disappointed to hear that. May be unfair for us old users :( Months ago, I tried hard to install the SYCL mode , but failed. Some users may even have no GPU. I hope the CPU mode can be updated as well.

[Xiangyu-Hu]

we have already ceased to the development of the old CPU code

Does it mean that no features will be added to CPU code? Disappointed to hear that. May be unfair for us old users :( Months ago, I tried hard to install the SYCL mode , but failed. Some users may even have no GPU. I hope the CPU mode can be updated as well.

we have already ceased to the development of the old CPU code

Does it mean that no features will be added to CPU code? Disappointed to hear that. May be unfair for us old users :( Months ago, I tried hard to install the SYCL mode , but failed. Some users may even have no GPU. I hope the CPU mode can be updated as well.

Actually, the SYCL (actually CK version not relevant to GPU at all) version also works on CPU,
it is just a new programming paradigm. You can check that all test cases in test_sycl can be run on CPU.

For particles dynamics without involving neighbors, you can even mix them with the old CPU code.

[Jasmine969]

You can check that all test cases in test_sycl can be run on CPU.

That's great. I tried it just now, it worked, but a bit slower than the old CPU code (2d_dambreak, 22 sec vs 15 sec). I will transfer to this new paradigm gradually.

[Xiangyu-Hu]

You can check that all test cases in test_sycl can be run on CPU.

That's great. I tried it just now, it worked, but a bit slower than the old CPU code (2d_dambreak, 22 sec vs 15 sec). I will transfer to this new paradigm gradually.

Great and Yes. It is a bit slow as it only save neighbor list but compute kernels in particle dynamics. However, it does not slower too much as the new computers all are memory bond not computing bound.