Question #698253 on Yade changed: https://answers.launchpad.net/yade/+question/698253
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 updates. 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. Cheers Jan -- You received this question notification because your team yade-users is an answer contact for Yade. _______________________________________________ Mailing list: https://launchpad.net/~yade-users Post to : [email protected] Unsubscribe : https://launchpad.net/~yade-users More help : https://help.launchpad.net/ListHelp
