In the issue KratosMultiphysics/Kratos#278 @RiccardoRossi , @maceligueta , @philbucher and me were talking about How should the problemtype write the conditions:
I've written this, trying to clearify some ideas (forgive me for the extension):
From the problemtype side, the most efficient way is to print the GiD element id.
Let's call this the A way of writing the conditions.
That is done using the customLib C++ lib, so it is faster and allows to handle larger number of elements than the current way of printing the conditions' block, in TCL.
The B way is do what we are doing now, each app implements it's way of printing/storing the conditions (or uses the common functions to do so). At this point, the pseudo-code looks like this:
In the Begin Conditions sections:
foreach condition in conditions: //(in the tree)
foreach group in GetGroupsOf(condition)
print "Begin Condition _ConditionName_"
foreach element in GetElementsOf(group)
nodes = GetNodesOf(element)
print "i 0 nodes"
++i
print "End Condition"
Store(condition,group, initial_id, end_id)
Each condition-group stores its interval of ids, to print them later in the submodelpart.
In the submodelparts sections:
foreach condition-group in GetStoredConditionsGroups // previously stored
Print "Begin SubModelPart _condition-group_
Print "Begin nodes"
foreach node in GetNodes(group)
print node
Print "End nodes"
Print "Begin conditions"
i = condition-group.getInitial
while i < condition-group.getFinal
print i
++i
print "End conditions"
print "End subModelPart"
Let's compare
THE A WAY:
pros:
- Increased performance (C++ writing)
- Easier implementation (we do not need to keep control of assigned ids)
cons:
- Points are meshed as nodes, not as '1 noded elements', so it's ids are assigned as nodal id (We'll see it in an example). Dr. Abel Coll (manager of the GiD dept.) has explained me that he can change something in the GiD tcl API to get nodes meshed as elements.
- Conditions id will not be consecutive
- As @maceligueta said, it will be impossible to get different id for the same entity, if you need so.
THE B WAY:
pros:
- It is already implemented
- Conditions on nodes have a valid id assigned, without telling GiD to change it's meshing criteria
cons:
- Lower performance (TCL writing)
- Lower amount of elements (TCL can store lower information in a variable, remember the BCN model problems)
- Difficult implementation
- The fact of storing the 'invented' ids makes dificult the interaction between apps
- Each app has needed to implement it's own system to control the assigned ids
EXAMPLES:
Imagine this geometry:
Groups assigned:
Body: the only surface
Top: The top line
Left: The left line
After meshing it, we get the following elements and nodes (elements in gray, nodes in black):
So assigned groups will have:
Body:
6 Nodes: 1 2 3 4 5 6
4 Elements (4 Triangle): 1 2 3 4
Top:
3 Nodes: 2 4 6
2 Elements (2 Linear): 5 6
Left:
2 Nodes: 1 2
1 Elements (1 Linear): 7
Imagine that we assign (in the kratos tree):
LINE_LOAD_CONDITION <-> Top -> with some properties
LINE_LOAD_CONDITION <-> Top -> with other properties (interval changes...)
LINE_PRESSURE_CONDITION <-> Top -> with some properties
LINE_LOAD_CONDITION <-> Left-> with some properties
The A way mdpa could look:
Begin Conditions LineLoadCondition2D2N// GUI group identifier: Top
5 0 2 4
6 0 4 6
End Conditions
Begin Conditions LinePressureCondition2D2N// GUI group identifier: Top
5 0 2 4
6 0 4 6
End Conditions
// Note that we are applying two different conditions to the same ids, and we need to repeat their connectivities
Begin Conditions LineLoadCondition2D2N// GUI group identifier: Left
7 0 1 2
End Conditions
Begin SubModelPart LineLoad2D_Top // Group Top // Subtree LineLoad2D
Begin SubModelPartNodes
2
4
6
End SubModelPartNodes
Begin SubModelPartConditions
5
6
End SubModelPartConditions
End SubModelPart
Begin SubModelPart LinePressure2D_Top // Group Top // Subtree LinePressure2D
Begin SubModelPartNodes
2
4
6
End SubModelPartNodes
Begin SubModelPartConditions
5
6
End SubModelPartConditions
End SubModelPart
//Note that it's the same for both
Begin SubModelPart LineLoad2D_Left // Group Left // Subtree LineLoad2D
Begin SubModelPartNodes
1
2
End SubModelPartNodes
Begin SubModelPartConditions
7
End SubModelPartConditions
End SubModelPart
Meanwhile, the B Way is looking like this:
Begin Conditions LineLoadCondition2D2N// GUI group identifier: top
1 0 2 4
2 0 4 6
End Conditions
Begin Conditions LineLoadCondition2D2N// GUI group identifier: left
3 0 1 2
End Conditions
Begin Conditions LinePressureCondition2D2N// GUI group identifier: left
4 0 2 4
4 0 4 6
End Conditions
Begin SubModelPart LineLoad2D_top // Group top // Subtree LineLoad2D
Begin SubModelPartNodes
2
4
6
End SubModelPartNodes
Begin SubModelPartElements
End SubModelPartElements
Begin SubModelPartConditions
1
2
End SubModelPartConditions
End SubModelPart
Begin SubModelPart LineLoad2D_left // Group left // Subtree LineLoad2D
Begin SubModelPartNodes
1
2
End SubModelPartNodes
Begin SubModelPartElements
End SubModelPartElements
Begin SubModelPartConditions
3
End SubModelPartConditions
End SubModelPart
Begin SubModelPart LinePressure2D_top // Group top // Subtree LinePressure2D
Begin SubModelPartNodes
2
4
6
End SubModelPartNodes
Begin SubModelPartElements
End SubModelPartElements
Begin SubModelPartConditions
4
5
End SubModelPartConditions
End SubModelPart
As you can see, both ways have more or less the same information, but in A, is GiD the one who assigns the ids, meanwhile in B, it's the problemtype.
Anyway, I still thinking that MDPA should only be a full dump of GiD Groups information (nodes and elements)
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent