← Back to team overview

yade-users team mailing list archive

Re: [Question #698253]: Access to body material properties


Question #698253 on Yade changed:

Jan Stránský posted a new comment:
Disclaimer: I have no knowledge of your requirements, so some of the below comments might be false or even stupid.
So please for further discussion, describe "by words" your aim, its consequences etc.

>From the code segments, it seems you want some temperature/heat quantity

Does the heat stuff belong to NewtonIntegrator at all?
Does the values / their change influences the integration (which the integrator is for)?
If not (which I assume for the rest of this text), probably a separate engine (e.g. HeatQuantitiesUpdater) would be a better place for such code.
If it is only applicable for CpmMat, maybe something like CpmStateHeatUpdater should be created.

Also, it seems you are changing Cpm stuff significantly.
If it is the case, consider creating a new material/phys/law, either derived from Cpm or "copied" from Cpm, but derived from FrictMat. Something like CpmHeatMat or other more suitable name.
Or maybe adding these general heat-specific quantities "higher" (Material? FrictMat?)?
Usually there are a few material instances in the simulation, so a few more attributes is no issue (contrary to state, shape etc., exclusively individual for each body).

NewtonIntegrator is a "general" class.
As such, it should not include specific material class (this is the main antipattern). You include CpmMat. Why not FrictMat or ViscElMat?
If, in the future, somebody creates a new material, will it be necessary to include it to the NewtonIntegrator files?
Currently, NewtonIntegrator even does not use the (most base) Material class at all, it only depends on (the most base) State class.

A note to the OP. Inside the CpmMat, you have stuff like "stress from
previous iteration", "yield point form previous iteration", "cummulative
plastic strain". These all does not belong to material (imagine there is
just one material for entire simulation), these "state" quantities are
meant to be put to State or IPhys (contrary to one-per-simulation
material, there is separate State for each body and separate IPhys for
each interaction).

As said:
For your own "one purpose" implementation, do whatever gives you desired results in desired time, no matter the code is "not clean".
For public code, which should be maintainable in long-term scale, the code should be "clean" - commented, documented, the class structure and their interplay (i.e. includes) should be logical, etc. etc.

Also there are different levels of this.
The code should be "brilliant" for classes like NewtonIntegrator and core stuff, because everybody uses them.
If you create "leaf" material (plus state, phys, law, etc.), like Cpm, you do not need to be so strict, as not everybody uses it and it is (should be!) included nowhere or on very limited amount of places. E.g. Cpm in ConcretePM files is self-contained. It is only included in VTKRecorder, because VTKRecorder provides extra "cpm recorder", not usual for most materials.


You received this question notification because your team yade-users is
an answer contact for Yade.