...
...
...
Create the following relations in Entity “Mass Hull“;
...
Include the following parameters in Entity “Decks“ (Child of entity “Mass Decks”): “Nr”, “Name$”, “Area”, “Weight_area_factor”, “Mass”, “COGX”, “COGY”, “COGZ”, “MOMX”, “MOMY”, “MOMZ and “QEntityData”.
...
Take care that, with exception of parameter “Nr”, all parameters are placed within the table view (instantiate parameter and provide attribute @MULTVAL in Data Slot). See also Figure 81.
The number of cases is equal to the number of defined decks by the user in the “Lay out” Entity. We are going to get this information. Create the following relation.
The first column/case of the table should contain data (Name$ and Area) from the first defined Deck in Entity “Deck. The second column contains data from the second defined deck, etc. This can be done by the following relations.
In this relation, QEntityID = xx refers to the value of QEntityID of the multiple Entity “Deck” that is a child of Entity “Decks”, see section 2.3.9.
When you want refer to a multiple Entity, you also have to indicate the QEntityIndex. Quaestor automatically Quaestor automatically provides an index value in the Quaestor parameter the Quaestor parameter QEntityIndex for each multiple Entity. So ENTITY#(xx, 3) refers to the third defined Entity “Deck”. The functionORCA(1) returns the current case number which is now being executed. So for the second column/case in a table the value of ORCA(1) = 2. When we combine the index with the ORCA() function, like in Area = ENTITY#(xx, ORCA(1)).Area, the second column of the current table will refer to the area from the second defined deck, etc.
...
As already discussed in the “Deck” Entity, the Weight_area_factor is a bit special. What we want is that this property is connected to the original value in Deck (of which the value is hidden) but, when modified by the user, the modified value should be used in both the present Mass Decks>Decks Entity AND the original Entity (Decks>Deck).
This is done by means of the @SAVEINSOURCE attribute. Create the following relation:
Figure 80: Data slot of "Weight_area_factor"
...
Include the following parameters in Entity “Bulkheads” (Child of entity “Mass Bulkheads”): “Nr”, “Name$”, “Area”, “Weight_area_factor”, “Mass”, “COGX”, “COGY”, “COGZ”, “MOMX”, “MOMY”, “MOMZ and “QEntityData”.
Take care that with exception of parameter “Nr” all parameters are placed within the table view (instantiate parameters and provide attribute @MULTVAL in Data Slot).
We want to get the data for “Nr”, “Name$”, “Area” from parameters in Entity “Bulkheads” (Child of Entity “Mass Bulkheads”). We connect to this data through the following relations (in all expression QEntityID = xx refers to the Entity “Bulheads” that is a child of Entity “Bulkheads”, see section 2.3.11. This Entity “Bulkheads” is a singular obligatory Entity which also contains a table):
Next create the following relations in Entity “Bulkheads” that is a child of Entity “Mass Bulkheads”:
As already discussed above, the Weight_area_factor is a bit special. What we want is that this property is connected to the original value in Bulkheads (of which the value is hidden) but, when modified by the user, the modified value should be used in both the present Mass Bulkheads>Bulkheads Entity AND the original Entity (Bulkheads>Bulkheads).
This is done by means of the @SAVEINSOURCE attribute. Create the following relation:
Please note the difference with the previous paragraph, in which a table was created referring to values within multiple entities. For the bulkheads we have created one table and refer to values within the table of another singular Entity
...
Assign the following text for “QEntityRef”; “Cargo mass calculation: summation of all cargo components”
...
Take care that with exception of parameter “Nr” all parameters are placed within the table view (instantiate parameters and provide attribute @MULTVAL in Data Slot).
In Entity “Cargoes” we enable the user to create a table with a number of cargo objects. For each object the user has to provide a name, COG and mass. Create the following relations:
...
Figure 83: Entity "Cargoes" to define number of cargo objects
...
Back to content | Continue with Intact stability calculation >>