Usually a problemtype is evolving along the time, the name and version is declared in the <problemtype>.xml file

The number of the version must be increased in each released version.

A model using a customLib-like problemtype will store the version in the .spd file

When reading a model with a different version will try to invoke some transform procedures, to try to update the old problemtype data to the current definition.

Sometimes is not possible to know automatically how to assign and old name to a new name of data, to handle this case is possible to create a <problemtype>.transform file that drives this map.

The syntax of the .transform are simple Tcl list, with <KEY> <SUBKEY> <values> like this

CONDITION RENAME {<old_condition> <current_condition>}

CONDITION RENAME_QUESTION {<old_condition> <old_question> <current_question>}

BLOCKDATA RENAME_QUESTION {<old_blockdata_n> <old_value_n> <current_vallue_n>}

e.g. consider a cmas2d_customlib version 0.1 with this kind of .spd file

<cmas2d_customlib_data version="0.1">

...

....

...

that has evolved in the version 1.0 to other names like this:

<cmas2d_customlib_data version="1.0">

...

...

...

A file like this <cmas2d_customlib>.transform (placed in the problemtype) can handle these changes and convert a model v 0.1 to the current v 1.0

#map changes from v 1.0 to 2.0

CONDITION RENAME {Point_Mass Point_Weight}
CONDITION RENAME {Plates Shells}
CONDITION RENAME_QUESTION {Point_Mass Mass Weight}

BLOCKDATA RENAME_QUESTION {material specific_weight Density}

There are more specialized keys like these:

CONDITION XPATH {<old_condition_name> <old_condition_xpath> <current_condition_xpath>}

This maps a customlib condition n="old_condition_name " and matching the xpath old_condition_xpath to the current xpath

e.g.

To combine the Kratos 6.0 to Kratos 9.3.2

condition Parts, depending on the parent container n attribute==Structural and the child value with n==Element and v==SmallDisplacementElement2D are mapped to a new condition name Parts_Solid.

and condition parts ot container Fluid are mapped to the current condition FluidParts

CONDITION XPATH {Parts {//condition[@n="Parts" and parent::container[@n="Structural"] and child::group[child::value[@n="Element" and @v="SmallDisplacementElement2D"]]]} {//condition[@n="Parts_Solid"]}}

CONDITION XPATH {Parts {//condition[@n="Parts" and parent::container[@n="Fluid"]]} {//condition[@n="FluidParts"]}}

CONDITION COMBINE_QUESTIONS_PROC {<old_condition_name> {<old_question_1> <old_question_2>} <current_question> <tcl_proc_name_to_combine> <value_string_0 ... value_string_3>}

This combine tho old boolean question values into a single new question with 4 possible combined values.

e.g.

To combine the Kratos 6.0 condition DISPLACEMENT with boolean (True or False) values constrainedX and ByFunctionX into a current Kratos 9.3.2 single value named selector_component_X with 4 possible string values "Not ByValue ByFunction ByValue"

CONDITION COMBINE_QUESTIONS_PROC {DISPLACEMENT {constrainedX ByFunctionX} selector_component_X gid_groups_conds::transform_combine_two_dom_boolean_values {Not ByValue ByFunction ByValue}}

For a problemtype 'classic' (without the customLib xml tree) can be used other keywords, to map general data, interval data, and materials

GENERAL_DATA RENAME_QUESTION {<old_question> <current_question>}

CONDITION RENAME {<old_condition> <current_condition>}
CONDITION RENAME_QUESTION {<old_condition> <old_question> <current_question>}

MATERIAL RENAME {<old_material> <current_material>}

MATERIAL RENAME_QUESTION {<old_material> <old_question> <current_question>}

Browser not supported