Compare that to Catia's implementation of an intuitive, easy to use
FE System, GPS (Generative Part Stress Analysis). GPS uses tetrahedal
elements only. :-)
That seems to be the trend with most Free FE program now, only implementing one or a few elements, which really sucks. For example, if you need to simulate a pin, that is, a part that has rotation about 1 axis and no translation, you would use very high coefficient springs. You really can't do this with any of the shells or solids because they, theoretically, do not transfer rotation about any axis (at least that's the way I learned it).
Using versions is a good idea, I'll have to look into that as it will be definitely useful for future development.
As for the FEMaterial class, I realized I needed it last night and have now accounted for it. I tool all material properties from the FEElement, which really made no sense having them in there, and created a FEMaterial with them.
The FEMaterial class brought up an interesting problem for me though, I really have no idea when I should create a class or create a new type. I could easily create a new type using a structure to define FEMaterial as it only has some simple information on it and at the some functions to change those values. However I don't know if this would be better than creating a subclass of NSObject, adding the properties I need as instance variables
and creating methods to change the values. This becomes even more confusing, for me at least, with FENode as all
I need to do is change values since I will have all code to bring
everything together and solve it in a different class. Both approaches are used in GNUstep-core (ie NSRect, NSSize, etc) but I don't know when one should be used over the other. Resource usage is a big issue here seeing that, like I said before, simple models will generally have a few hundred nodes and complex ones over a million. The same issue goes for materials, but at a much smaller scale.
Stefan