I agree there may be no need of 2 classes "InitialValue" and "BodySource", but for sure need 2 functions, makeInitialValue(), makeBodySource(), or even more, makeHeatSource, makeSelfWeight() , et, to help script users. while makeAcceleration() is a better way than selfWeght, see Ansys FEM, there is centrifual, linear acceleration.
I would love the idea, "FemConstraintGeneric", that is why cfd module only got one Contraint. instead of 10+.
TaskPanel can be shared, just fill the UI with different label, unit, etc, it is then data-driven UI design.
Here is new design proposal
1) base class: "FemConstraintGeneric"
1.1) ShapeTypeList property may be sufficient, there is no need for those below
also an optional: PreferedShapeType
1.2) "Category" enum property:
1.3) References: to select geometry apply the constraint to
1.4) Settings: PythonObject
"ConstraintType" property, is reserved to name more specific type
"Velocity" "Pressure"? or let user specify in Settings python dict
2) view provider and task can be shared, but icon can selected according to Category
so they can have different icons and limited geometry selection to only one type, to reduce chance of selection error by mouse. FEM constraint can apply to point, edge, face, body, but for other domains, one boudnary condition type can only apply to one kind of topo.
3) Further, makePressureConstraint() and PressureConstraintCommand .. otherwise, too much abstraction will make users' life hard.
4) It does not enforce any constraint must derived from that generic class, if this constraint is so special.
In the longer term: geometry selecton widget, may add support of
1) link to imported femsmeshset/group(Joha2's commit) to support external imported mesh (Cfd module has this method)
2) a way to select internal edge, body, etc. I know there is some ongoing work.
3) body source and initial value may need some box, sphere parameters to define a region, but it is not real geometry.
4) if Coin drawing can be customized in Python, then lots of C++ contraints can retire. at least do not add more to C++.
The current widget, does not support Quantity, because there is an issue, any new quantity unit needs to be registered to work properly, while I donot know. see the bug description in my another thread.
but body source could be a constraint acting on a vertex. For example we could implement the constraint displacement as body source constraint.
Or would this be a generic initial value constraint?
Self weight would be a generic initial value constraint, than?
There is no such term InitialValueConstraint, we'd better call it just "InitialValue". Vertex constraint and point body source, they are different concept from user's view. At GUI, TUI level, they should be split into 2. my opinion.
bernd wrote: ↑
Fri Feb 21, 2020 5:52 am
just because we need to present two objects to the user, it does mean we need to implement two objects.
Slowly I get an idea. May be we only make one base object, FemConstraintGeneric.
All these new constraints are inherited from this.
BTW: do you have abetter example than Initial Temperatur? Since this exists already as object and in writers of elmer and ccx I would like to keep it ATM. Better implement some new constraint because of problems in the regard of backward compatibility. We could move existant contraints if this new generic object has proven to be useful for some time in master.