This question I should have sent by personal email but I thought that putting it here will lend its answers to the eyes of other "newbie" developers like myself who have similar concerns - namely designing their own classes so that when time comes it will not be a big problem to integrate their code into Opensees if it proves worthy. We do not want Frank & Co. to be pulling at their heads and cursing us when we hand them a poorely-implemented bunch of new classes. Better bug them with our questions now and come out with clean codes than the other way around. So, the story is:
I have developed a uniaxial material that takes into account confinement, along with a modified fiber section which has one additional "UniaxialMaterial*" member variable and a modified "setTrialSectionDeformation" function as the main deviations from teh original fiber section. Supposedly, it will behave the same as the original fiber section for any material other than my own. However, if a fiber is made of my new material, it will call the material's "setTrialStrain" method with one extra parameter and/or will query it for the confining stress using an access function "getSig_l()". The questions are:
1. Does it matter much if I make the new fiber section a subclass of FiberSection and avoid a lot of code duplication and maintenance later, or a subclass from SectionForceDeformation like all other section classes directly as it currelty is? If so, which way?
2. For the section to call the new material's overloaded "setTrialStrain" method with three parameters, I have to add an interface of a corresponding virtual method to the UniaxialMaterial.h file - otherwise the compiler won't recognize the method. This virtual method will neetly redirect to the material's original "setTrialStrain" method for all materials except the new one. However, this means I will be adding code to an existing file which I did not author (and I hate it when somebody does this to a file I authored). It also makes later itegration of my classes into OpenSees less simple. Is there a way around it?
3. Similar to (2) but simpler, for the section to query the new material's overloaded "getSig_l" method, I have to add an interface of a corresponding virtual method to the UniaxialMaterial.h file. This virtual method will return "zero" for all materials except the new one. Again, is there a way around it? I thought of making the new section a "friend" of the new material so that it can get access to its member variables without using access functions but this will mean that the material can only be used in this section and that it will have to be recompiled to add more "friends" as time goes by - which does not sound correct. Any advices?
Thanks and, again, apologies for the headache.
MMT
Coding Style
Moderators: silvia, selimgunay, Moderators