You are not logged in. Please login or register.
OOFEM forum → Developers Discussion → I want to break backwards compatibility
This is a list of things I would like to see change, which unfortunately breaks backwards compatibility with input files.
I make a wiki page so anyone with ideas can contribute:
http://www.oofem.org/wiki/doku.php?id=new-input-files
I don't plan on doing any of those changes anytime soon, but it is a good idea to have a plan.
I don't have any contributions of my own at the moment but I agree with the points raised.
Also in regards the meeting notes from Prauge point 4 - about reducing the number of engineering modules: I think we should aim for having only static and dynamic in the SM-module and transient in the TM-module. Over time it will be very difficult to maintain every possible offspring that might pop up e.g. adaptive nonlinear dynamic etc.
I have one more idea, which definitely breaks all backwards compatibility.
Materials should be applied to cross-sections instead of elements.
@Jim
I would say that's not really a problem with backwards compatibility. The engineering model name, would at most be a single line in the input files. Having to modify nearly every line in huge files is more of a problem (especially if its more than a simple search-and-replace).
Another input field that needs to be changes is "nip"
Instead of giving the total number of integration points, we need to supply 1 value per dimension (for cubes), or the total number of points for triangles, or the total number of trianglepoints + the out-of-plane points for wedges, etc.
In short, we need an IntArray with 3 values for cubes, 2 values for squares, 1 value for triangles and tetrahedrons and lines, 2 values for wedges. It is more flexible and an absolute necessity when dealing with composites.
I think that break of backward compatibility needs not be a big issue if there will be a converter from the old format to the new format of input file available in OOFEM distribution.
Martin Horak asked me a question through email about the cross-section, I'll answer here in case someone else is wondering:
I read at the forum that you would like to apply materials to cross-sections instead of elements. What is the reason for doing this? I have input file where almost each element has different material, so I have something like two thousands of elements and one thousands of materials, but I need only one cross-section. If you introduce the change I will need also lots of cross-sections and the input file would become even more messy. It is not a big problem for me, I just don't see any advantage doing this.
We already do this when you use anything but the simple-crosssection. So with e.g. layered cross-section you have to add a dummy-material number to the element itself, and hope that nothing ever asks for Element::giveMaterial because it would be incorrect. The assumption 1 element == 1 material isn't generally true, that's why I'd like to see this removed. Even continuum elements (wedge and cube) support layered-crosssection, so its not just structural elements that make use of this.
It is also simpler for most "normal" input files. You have a bunch of elements that you have in one cross-section, then just assign the material once.
In extreme cases where one has thousands of materials.. then i suspect that the real issue is that one has varying material parameters, all for the same material model.
This is something which I've been thinking about as well, as I have the same type of material (i.e. FE^2 material) but with varying subscale problems (i.e. varying material data). In these cases one also probably wants to different data in every gauss-point, but only one set of material parameters per element is as fine-grained that we can do right now.
I would like to improve that as well, and it possibly be handled by a cross-section that can somehow define a field for whatever parameter you need to vary. I'm welcome to hear ideas and recommendations for such implementation.
Hi Mikael,
in fact there is already support for varying material data. There is a material extension, called RandomMaterialExtensionInterface, which adds support for this. The varying materials parameters are user configurable. The user in general can select which material parameter is going to be generated, and select generator for this parameter. This is done using an instance of RandomFieldGenerator, the generated parameters are stored in associated status. The whole concept requires, that material parameters are accessed using give method. For reference, see randommaterialext.h and randommaterialext.C. As an example of material implementing this, see IsotropicDamageMaterial1.
The class names are somehow related to the first application, where some parameters were generated using random field generator, satisfying some prescribed properties.
Hi Borek,
I actually don't want the data randomized. An example of what I would like is varying density (in a compressed powder). The tricky part would be to describe the variations. Either an explicit fomula, or some interpolated nodal values. But the randommaterialext could be a good starting point.
I have encountered some more problems with the element storing a material number.
1. Updating materialstatus is broken right now. It asks the element for the material, which, can't possible all different materials in a layered cross-section. Material status is then *silently* never updated. No warnings, just incorrect results. This is a very serious bug.
2. Checking if the material stiffness matrix is symmetric is also broken for the same reason.
Everything that calls Element::giveMaterial() is actaully broken, but these are the two most serious offenders.
I've started working on a script to convert files. I think we should look over the names of the elements (as have been discussed previously).
You can find it in "tools/version_upgrade.py"
I suggest using a name that consist of "problemtype_discretizationtype", though its not all that clear what the name should be.
For example:
tr21stokes -> stokes_tr21
tr1supg2axi -> supg2axi_tr1
though it becomes less clear for a lot of elements in the SM module.
lspace -> solid_hexa1
question is what sort of abbreviations we should stick to, and how we condense the discretization type in more complex cases. For example the 27 node hex element compared to the 20 node hex element? Should we go for "***_hexa20" and "***_hexa2" ?
I have another idea I'm just going to throw out there. Going through these elements, we get a lot of almost duplicate elements in the 2D case.
plane stress, plane strain, axisymmetric.
Perhaps we should let the cross-section determine which of these three modes should be used?
Hi Mikael,
I have also noted the quite large redundancy in the 2D elements.
I think it would be excellent to let the cross section determine which mode to use.
/Erik
OOFEM forum → Developers Discussion → I want to break backwards compatibility
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.