| Thread Previous • Date Previous • Date Next • Thread Next |
Better derive a class for continuum like materials (see below). It is not very good to add more data when most code will not use it.Actually just today we were discussing there the equilibrium distance concept. My conclusion is that it should be added to ScGeom so that it works for those "continuum-like" materials.
Is it really a hack? Equilibrium distance can be seen as a physical variable of the contact. It can change to reflect damage, etc. This is perhaps the best option : no added data in ScGeom, no new Ig class.In fact, it was the biggest obstacle when I tried (never finished) to adapt the Cpm model to ScGeom. The option was to store the initial distance in CpmPhys (which is actually, looking at your code, what you do actually with CFpmPhys::initD), but I did not go along that path as it would be only a hack.
This is how I see things : usually, when people say "it follows Plassiard", they mean variables have the same names and all assumptions and conventions in parameter definitions, micro-macro passage, and such are the same. It is not really the good question for sorting contact laws. Defining kn=E.D (for instance) is just a question of modelling, not computing, and as such, it is out of the scope of law functors. Different users will always do that differently, and it should be handled in Ip functors. OTOH, computing relative torsion/bending between two bodies will always be done with the same algorithm. Same for returning moment=k*rotation, regardless how k is defined. So, most of diffs between the 3 law functors could/should actually be confiined to Ip data and functors.What about the other 2 laws? Chia Weng's law is cohesionless and follows faithfully Jean-Patrick's paper, that is what I gathered. Janek's law (Law2_ScGeom_CohFrictPhys_ElasticPlastic) differs in that is has additionally twist and tension? Is there a paper that describes it?
Not in ScGeom : relative rotation needs initial orientations of each bodies stored in the interaction -> we want no more data in ScGeom. The plan is to add data in the future 6DofScGeom and move the moment code in there. Currently, this data is in interaction physics.[The best would be to provide a few functions (to ScGeom or some more complex class) that would handle bending and twisting, similarly to how ScGeom::rotate() handles shear displacement. Then respective models would make use of them to get their work done in a few lines.]
About documentation, don't be too pessimistic. The algorithm for rotations is easy to understand (provided you exclude all aspects regarding Poisson, Young, and other modelling tricks, as suggested above).
Bruno
| Thread Previous • Date Previous • Date Next • Thread Next |
