Bruno Chareyre a écrit :
>
>>
>>
>> I modified 2 or 3 lines in TriaxialCompressionEngine in order to
>> update the friction angle from compactionFrictionDeg to FrictionDeg
>> when the state transition is performed manually (by editing the .xml
>> file) from Iso_compaction to Triax_loading. (but I am not sure to
>> respect the idea of the person who written this part of the code)
>>
> It makes sense. I will review your changes when you will have them
> committed.
>
>
>> In addition, during the state transition, I would like to update the
>> tangent of friction angle for all interaction and not only "real"
>> interaction
> Why?!
> By design, interactions which are not "real" have really no reason to be
> considered. See them as if they don't even exist. They will be seen as
> "new" interactions if, by any chance, they become real again. So, they
> will be re-initialized anyway, and your updated values will be
> overwritten before they can be actually used.
> Did you try it already? I suspect it would lead to some i->friction = x
> with i the null pointer, then Yade crash.
Ok your are right, I forgotten this point: for some of these non real
interactions "variable" friction does not exist. Well, I am just
perturbated to see sometimes in xml files wrong friction values even if
they correspond to non real interaction. But, ok, that is not a problem.
>> (from a discussion between Jerome and Bruno I understood that the
>> transition (isReal = 0 and isNew = 0) => (isReal = 1 and isNew = 0)
>> will not happen, but I would prefer to have several "protections" than
>> only one).
>>
> Sticking with the current design rule is the best way to avoid problems
> if you ask me. If this transition from (0,0) to (1,0) could occure, it
> would be a major bug, and a correct value of friction would not help a
> lot (think about the tangential displacement, which would be totally
> wrong : current_position - position_when_the_contact_was_lost).
>
>> My question: I may want to submit code modifications in opposition
>> with previous developments. Thus, what is the philosophy? submit
>> directly these modifications to svn, or via a yade developer who will
>> filter the modifications?
>>
> Personnaly, I'd prefer people to at least point it out when they modify
> some code that I'm developping/using (Triaxial and related classes).
> Exactly like you just did. The commit itself can (should) be done by the
> one who modified the code (you).
Ok, I understand, I would like too if I were you!
Thanks
>
> To summarize :
> 1/ For changing friction after manual editing - or any other change
> consistent with current philosophy : let you commit your change.
> 2/ For accessing unreal values, it is really not consistent with the
> current contact logic. If you really want this behaviour, or anything
> else in opposition with previous logic, it is better to create your own
> separate class.
>
> An important point when you modify an existing class : your changes must
> keep the default behaviour unchanged (might sound obvious).
> One usual way for this is :
>
> class C {
>
> + bool newFeatureActivation;
> }
>
> in the constructor : newFeatureActivation = false, and then define the
> modified behaviour in a if (newFeatureActivation) { ... }.
>
> This precaution is not needed for your friction update though, as it is
> already doing nothing by default.
>
> Bruno
>
>
--
Luc Sibille
Université de Nantes - Laboratoire GeM UMR CNRS
IUT de Saint Nazaire
58, rue Michel-Ange - BP 420
44606 Saint-Nazaire Cedex, France
Tel: +33 (0)2 40 17 81 78
_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : [email protected]
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp
_______________________________________________
yade-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/yade-users
