The mtest interface to aster behaviours must mimic as much as possible the behaviour of Code-Aster. I thus asked Code-Aster developpers how this case is handled to fix this problem appropriately.
Sincerly,
Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The question is : what is the value of NPROPS when no material properties has been declared ? For state variables it is 1 since fortran does not allow empty array (and has no null pointer).
However, from an QA point of view, a mechanical behaviour shall never have a material property. Otherwise, it would mean that part of the physics is given in the user input file, which is bad : it is difficult to check what property the user used and if it is verified. See the mfront tutorial for a discussion.
Material properties have been used to create "generic behaviours" in the old days when creating a new material behaviour was considered difficult. MFront tries to eliminate this difficulty and remove the need of generic behaviours and allow builing material knowledge management projects with strong emphasis on Quality Assurance. This is what we have done in the PLEIADES platform.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Elodie for this bug report.
The mtest interface to aster behaviours must mimic as much as possible the behaviour of Code-Aster. I thus asked Code-Aster developpers how this case is handled to fix this problem appropriately.
Sincerly,
Thomas
It's always possible but it's quite strange !
The question is : what is the value of NPROPS when no material properties has been declared ? For state variables it is 1 since fortran does not allow empty array (and has no null pointer).
However, from an QA point of view, a mechanical behaviour shall never have a material property. Otherwise, it would mean that part of the physics is given in the user input file, which is bad : it is difficult to check what property the user used and if it is verified. See the mfront tutorial for a discussion.
Material properties have been used to create "generic behaviours" in the old days when creating a new material behaviour was considered difficult. MFront tries to eliminate this difficulty and remove the need of generic behaviours and allow builing material knowledge management projects with strong emphasis on Quality Assurance. This is what we have done in the PLEIADES platform.
The issue has been solved in the branches trunk, rliv-2.0.x and rdev-3.0.
Sincerly,
Thomas