Tutorial 1 Getting started
| Learning goals
| Prior knowledge |
As mentioned earlier these tutorials are focussing on providing the basic skills of knowledge engineering. In this first tutorial, the main dimensions of a ship will be systematically varied. The knowledge used is Archimedes’ Law in combination with design requirements, which are the following:
...
Our objective is to generate a dataset of systematically varied ships that meet the design criteriarequirements.
...
Before starting with your knowledge engineering, please make sure you are actually using the knowledge engineering user level and you have Quaestor configured in the most convenient layout.
To check/change your user level go to the general tab of Tools>Options Tools -> Options -> General. You can change your User level. If you are not able to change it to Knowledge Engineer (level 3), you do not have KE rights. Please contact your ICT department or Qnowledge for the proper license.Furhtermore, for editing all kinds of properties it is convenient to use the Frame Viewer. Therefore in the Appeareance tab of Tools>Options select "Use classic frame viewer".
When Quaestor is started, an empty knowledge base is automatically created.
In the Knowledge browser, minimize the Quaestor node, and expand the NewQkb node (figure 1).
Figure 1 Expanding the Newqkb node
you are presented with the opening screen, with no knowledge base or project loaded:
To create your first knowledge base
The screen changes to the main Quaestor knowledge engineering screen:
When a knowledgebase node is expanded, like Newqkb
here, the classes When the knowledgebase node is expanded, the classes within the knowledgebase are visible. Classes are used to organise your parametersdata and equations, and put them in a practicable structure. The Top Goals/Undefined class is part of the knowledge base by default. Here, the goal parameters of your calculation (Top Goals) can be stored, as well as other parameters that don't belong to other classes (Undefined).
We'll create a new class named Main Dimensions, in which the following ship parameters are to be stored.
...
In Quaestor, all data is put in parameters. You can designate one (or more) parameter as the goal of the calculation.
Note |
---|
Classes are a means for organizing parameters for the user. They are not to be confused with a class in object oriented computer programming. The Quaestor core does not use the classes at all.It only uses the parameters! |
The Top Goals/Undefined class is part of the knowledge base by default. Here, the goal parameters of your calculation (Top Goals) can be stored, as well as other parameters that don't belong to other classes (Undefined).
Create a new class, named Main Dimensions, in which the following ship parameters are to be stored.
Lpp: Length between perpendiculars
B: Moulded breadth
T: Draught from keel to Construction Water Line
Main Dimensions
.Sub classes can be defined by right clicking on any class name and again selecting New Class.
Figure 2 Creating a new class in the knowledge base
The class is now shown in the knowledgebase tree, and we you can add the parameters Lpp
, B
and T
.
...
...
Main Dimensions
and select Knowledge -> New parameter/function from the main menu. Alternatively, click in the right part of the knowledge browser, and select New Parameter / Function (Ctrl+I)...
Lpp
and click the Value button to select its type. Repeat these actions for the parameters B
and T
.
The added parameters now appear Figure 3 By right clicking in the right -hand side part of the knowledge browser, parameters can be added The added parameters all appear like Knowledge browser like this:
The A red cross is a sign that the draws your attention to the fact that a parameter is not yet fully defined for the system to use it.
In Quaestor, a valid parameter has:
The first requirement is already satisfied, so let's assign dimensions to the parameters.
...
The first requirement is already satisfied, so let's assign dimensions to the parameters.
?
into m
, the dimension for Lpp
(meters)...
You can also add a reference for a In the larger area of the Frame Viewer, a reference can be assigned to the parameter. A proper reference is important, as users of the knowledgebase may not be certain of the exact meaning of the parameter. Please also read Documentation of knowledge for more details.
Provide Lpp with the reference Length of the ship (figure 4).
Figure 4 In the Frame Viewer, a dimension and reference can be assigned to the parameter
NOTE: The dimension of a parameter can also be assigned in the Slots & Properties window. Just scroll down to the Dimension row, and change the value.
Assign a dimension and a reference to the other parameters B and T, just as described above. Of course, the breadth and depth of the ship are defined in meters.
Now only the last requirement for valid parameters has yet to be fulfilled:
This qualification can be provided in the Slots & Properties window.
Select the parameter LPP. In the Slots & Properties window, scroll down to the Determined by row. Change the value to VR: User only, as the parameter LPP is input (instead of defined by a relation), see figure 5.
Figure 5 Let Quaestor know how a parameter should be determined
Notice that the status of LPP has changed to
to show that Quaestor knows enough about this parameter to use it in a computational model.
Make sure that B and T are determined by VR (Value Requested):User only too.
Note that above you have explicitly added Lpp, B and T as parameters to the knowledge base.
You are also able to implicitly add parameter by creating relations that contain new parameters. Quaestor will automatically add these new parameters to your knowledge base (so implicitly). You will see this next.
In order to define the loading capacity of the ship, it’s important to know the kind of water (Salt or Fresh) the ship will sail in. Therefore, we will add some relations and constraints, and make sure the user can select the watertype.
We'll add two relations, one for salt water and one for fresh water.
Select Top Goals/Undefined in the knowledge browser, in the right hand side and select New Relation (Ctrl+N). In the upper part of the new window, delete any proposal (Quaestor may have filled in the last selected parameter), and enter
(belonging to salt water), and press Save (figure 6).
Figure 6 Entering a relation
Note that when you enter a relation, Quaestor provides as much help as possible by means of the Help Checker. This checker shows what to expect (in this case a Value or an Expression, ValExp). After saving a relation, the Help Checker will check the syntax for possible errors, and shows a warning message when something is wrong.
Because of entering the relation, the parameter Rho has automatically been created. Furthermore, note and realise that the parameter is created in the Class in focus when saving the relation. For Rho to be a valid parameter, a dimension should be assigned.
Provide a reference for rho and assign it the dimension kg/m^3. Rho is now a valid parameter. Furthermore, make sure rho is determined by SYS: System/Equation, as a relation is used to determine rho.
The following might seem a bit unconventional: a second relation is given for Rho. This is a nice example of how quaestor works: In a calculation, Quaestor can find numerous calculation paths and automatically chooses the most appropiate one based on constraints and available data. An infinite number of relations can be assigned to one particular parameter.
Add the following relation (belonging to fresh water) in a similar way as described above
The two relations for the density of the water are only valid for their corresponding watertype. Therefore, a constraint is added to each relation. A constraint is simply a restriction for the validity of the relation.
Double click Top Goals/Undefined in the knowledge browser: all relations in that class are shown (this will work for any class). One can always edit a relation by selecting it and pressing F2 (or and select edit). This is also a useful method to find out which relation you actually selected.
Now the relation Rho = 1025 and select Constraint->Add New. In the upper part of the new window enter the following constraint:
and press Save (figure 7).
Figure 7 Adding a constraint to a relation
The constraint is now added, and a parameter named Watertype$ has been created. The $ at the end of the parameter name makes sure Quaestor recognizes it as a String value, and the dimension Str is automatically assigned (see also Quaestor syntax. We have to assign a determined by value to make it a valid parameter.
Make sure Watertype$ is determined by VR: User Only, as the user should provide the information concerning the water type.
We repeat the process for the other relation:
Add the constraint: Watertype$ = "FW" to the relation Rho=998. Note that the expression editor assist you with the presentation of existing parameters and intrinsic function. When you press enter while an existing parameter or function is blue, this parameter or function is placed in the expression editor.
Both relations are now connected to the corresponding watertype by means of the value of the string Watertype$. Note if Rho is needed in the calculation progress, Quastor will note that the watertype is needed and will ask the user for this value (because it is assigned User Only).
TIP: By selecting a parameter in the knowledge base and then double clicking the box below the knowledge base tree, the relations defining that particular parameter are visible (figure 8).
Moreover, when you select a relation in the knowledge base, and double click that box, the parameters that can be calculated by the selected relation are shown.
When single clicking the box, all connections to the parameter or relation are shown. See also information on the Knowledge Browser.
B
and T
, just as described above. Of course, the breadth and depth of the ship are defined in meters.Now only the last requirement for valid parameters has yet to be fulfilled: a way to be determined (input from the user or defined by a relation). This qualification can be provided in the Properties window.
Lpp
. In the Properties window, scroll down to the Determined by row. Change the value to VR: User only, as the parameter Lpp is input (instead of defined by a relation).
Notice that now, the status of the Lpp parameter has changed to
to show that Quaestor knows enough about this parameter to use it in a computational model. Now make sure that B and T are determined by VR: User only too. By the way, VR stands for Value Requested.
Note |
---|
If a parameter still shows a red cross when you have provided all needed property values, click on Top Goals/Undefined, and you will see the blue cross. |
Note that above you have explicitly added Lpp
, B
and T
as parameters to the knowledge base. You are also able to implicitly add parameters by creating relations that contain new parameters. Quaestor will automatically add these new parameters to your knowledge base (so, implicitly). You will encounter this in the following section.
Tutorial 1
, by selecting File -> Save as.In order to define the loading capacity of the ship, it’s important to know the kind of water (Salt or Fresh) the ship will sail in. Therefore, you're going to add some relationsand constraints, and make sure the user can select the watertype. Two relations must be added, one for salt water and one for fresh water.
Rho = 1025
(belonging to salt water), and click Save:
Note that when you enter a relation, Quaestor provides as much help as possible by means of the Help Checker. This checker shows what to expect (in this case a Value or an Expression, ValExp). After saving a relation, the Help Checker will check the syntax for possible errors, and shows a warning message when something is wrong.
Because of entering the relation, the parameter Rho
has automatically been created. For Rho
to be a valid parameter, a dimension should be assigned.
Info |
---|
The parameter is automatically created in the Class in focus when saving the relation! |
Rho
and assign it the dimension kg/m^3
. Rho
is now a valid parameter. Furthermore, make sure Rho
is determined by SYS: System/Equation, as a relation is used to determine Rho
.What follows now might seem a bit unconventional: a second relation is given for Rho. This is a nice example of how Quaestor works: in a calculation, Quaestor can find numerous calculation paths and automatically chooses the most appropiate one, based on constraints and available data.
Info |
---|
An infinite number of relations can be assigned to one particular parameter. |
Rho = 998
The two relations for the density of the water are only valid for their corresponding watertype. Therefore, a constraint is added to each relation. A constraint is simply a restriction for the validity of the relation.
Click Top Goals/Undefined in the Knowledge browser: all relations in that class are shown (this will work for any class). One can always edit a relation by selecting it and pressing F2 (or right click and select Edit). This is also a useful method to find out which relation you actually selected.
Rho = 1025
in the Knowledge browser and select Constraint -> Add New. In the upper part of the new window enter the following constraint:Watertype$ = "SW"
and click Save:
The constraint is now added, and a parameter named Watertype$
has been created. The $
at the end of the parameter name makes sure Quaestor recognizes it as a String value, and the dimension Str is automatically assigned (see also Quaestor syntax). You have to assign a Determined-by value to make it a valid parameter.
Watertype$
is determined by VR: User Only, as the user should provide the information concerning the water type.Repeat the process for the other relation.
Watertype$ = "FW"
to the relation Rho = 998
.
Note that the expression editor assists you with the presentation of existing parameters and intrinsic functions.
Both relations are now connected to the corresponding watertype by means of the value of Watertype$
.
Whenever Rho
is needed in the calculation process, Quaestor will note that the watertype is needed to determine the value of Rho
, and will ask the user for this value (because it is assigned to be User only).
When you select a parameter in the upper list, the relations of that particular parameter are visible:
Moreover, when you select a relation in the lower list, the constraints for this relationship are shown:
Figure 8 When selecting a parameter and double clicking the box indicated by the blue arrow, all relations defining that parameter are shown.
Because there are only two possible values for Watertype$
(SW or FW), it's easy to integrate a dropdown box.
...
...
Watertype$
in the Knowledge Browser, select the Parameter tab in the Properties window and in the Reference box enter the following lines:FW<EQ>Fresh Water
SW<EQ>Salt Water
Figure 9 A dropdown box is created by entering this information in the reference slot of the frame viewer
The use of a dropdown box will be clear in a later stage of this tutorial, when calculations are made. Note that you can add the @EQEXPLAIN attribute to in the Data box ('data slot') of the Watertype$
parameter (see Frame Viewer for data slot) in order to manipulated that display only "SaltwaterSalt Water" and "FreshwaterFresh Water" are shown in the dropbox (so without SW and FW).
On the basis of the earlier defined parameters and the block coefficient Cb Cb
, the displacement of the ship can be calculated.
...
...
DISP = Cb * Lpp * B * T * Rho / 1000
which defines the displacement of the ship in tons.
Note that two new parameters are created: the block coefficient Cb and the displacement DISPcoefficient Cb
and the displacement DISP
. In order to keep the knowledgebase meaningful, it is necessary to provide references, dimensions and determined-by values for these parameters.
...
Cb
and DISP
. Cb
has no dimension (-), DISP
should be in tons (t). ...
DISP
by 1000. The determined-by values should ...
...
Cb
, ...
...
...
DISP
, as the block coefficient is input and the displacement is determined by a relation. Verify that all parameters now have a blue cross instead of a red one in front of them:Let's perform our your first Quaestor calculation. A solution is always determined by one or more Top Goals. A top goal is a parameter (or object) that is your final calculation target, in this tutorial it's the displacement of the ship.
...
...
...
DISP
.Note that the sign the cross in front of DISP
changed to to , indicating that it's a top goal for the calculation.
Calculations and solutions are managed in the workbaseWorkbase. Here, solutions can be created, redone (with different data), examined and deleted.
...
...
...
...
The calculation progress is started, and Quaestor first collects wants to collect all input data (figure 10).
data in the Workbase window:
Figure 10 Input data for the calculation
Entering data is easy: just type a value for each selected parameter and press enter to switch to the next one.
...
B = 10 Cb = 0.55 Lpp = 60 T = 6 Watertype$ = SW (Salt Water)
Note that the input of Watertype$
consists of a dropdownbox, which we created in (4), see figure 11.
Figure 11 Watertype$ can be selected in a dropdownbox
a dropdownbox, which you created above:
After providing the data you have to press the button or "Accept input & Continue" the Next button to continue. The actual calculation is started now , and the right-hand side of the workbase shows the situation of figure 13. During the calculation, the box indicated with the blue arrow shows the status of the calculation.Because and because this is a very simple example, the final state is alost almost immediately shown.:
Figure 13 Status of the calculation and solution
The top goal (DISP
) is shown, together with all parameters that were used for the calculation. With these input values, the displacement of the ship is about 2030 tons.
So far, we you created one solution, which is shown in the workbase (figure 14).
:
Figure 14 All solutions are shown in the workbase
As mentioned in the objective, we'd like to you will create a dataset of systematically varied ships. We You could of course perform several calculations with different input data by hand, but it's much easier to use the ability of Quaestor to create multiple case solutions. To keep the complexity of this example within reason, we you will only vary the breadth and length of the vessel. Please note that due to some important conceptual reasons the latest Quaestor release can Quaestor can only perform calculations on ranges of parameters when you alreade already have created a solution..
...
...
...
...
B= 9(0.5)11
...
Lpp= 55(2)69
...
In this way, B
and Lpp
are defined by a range, given the start value, step size and end value. For example, Lpp
is defined from 55 to 69 meter, with steps of 2 meter.
Quaestor will ask if it should create a case matrix for Lpp
(figure 15),
...
Figure 15 Quaestor asks if a case matrix should be created click Yes (an explanation will follow).
You will see that the single value input is still in the list and the multi case values are in the table part of the Workbase. Press the button or "Accept input & Continue" the Next button to continue.
The new solution is now created. The fixed values are again shown in the right hand side of the workbase. The varying parameters (B
and Lpp
) and the corresponding solution for DISP
are shown in the lower part. Each row is a different case, identified by a case number(#1, #2, etc.), see figure 16.
row is a different case, identified by a case number(#1, #2, etc.).
Figure 16 Multiple case solutions are shown in the workbase, each row is a different case
What does the Case matrix question mean? Note that the variations of B
do not correspond to the variations of Lpp
: there are 5 values for B
and 8 values for Lpp
. If we you would have answered No to answered No to the Case matrix question, five variations of B would have been made, each one with the corresponding value of Lpp (the last 3 Lpp values would be omitted). In that way, there would be only five cases. As we answered yes to you answered Yes to the question, all possible combinations are considered, which results in 5*8=40 cases. You can easily notice the difference by creating a new solution with the same input values, but now answer no to the case matrix question.
Info |
---|
...
Ranges can be defined in multiple ways:
|
...
|
...
|
...
|
...
...
As it is, the
...
Our multiple case solution table is sorted by the breadth of the ship, as shown in figure 16. Suppose we. Now suppose you'd like parameter Lpp Lpp
to be the leading parameter in this table.
...
...
Lpp
. In the ...
...
...
...
Lpp
....
...
A lot of cases in our your solution don't meet the design criteria: a displacement between 2000 and 3000 ton. We could have fixed this by adding a constraint to DISP
, but another way is to use a filter filter in the solution table.
...
DISP
solution, and click ...
...
...
DISP
, ...
...
Figure 18 With a filter, cases that do not fulfill the filter conditions can be made invisible
Now, only the cases for which 2000<DISP<3000 2000 < DISP
< 3000 are shown in the table. Our objective has been completed: we build The objective of this tutorial is now completed: you built a dataset of systematically varied ships that meet the design criteria.
You can verify your results by comparing it to [Tutorial 1 Finished] .