After speaking with @rubenzorrilla I thought on a method in order to automatically add variable/dofs/etc... This method would be complementary to Check method. My idea is a method like:
~cpp
Parameters GetRequirements(const ProcessInfo& rProcessInfo) const override
{
const Parameters requirements = Parameters("{
"required_variables" : ["DISPLACEMENT_X", "DISPLACEMENT_Y", "DISPLACEMENT_Z"],
"required_dofs" : ["DISPLACEMENT_X", "DISPLACEMENT_Y", "DISPLACEMENT_Z"]
}");
return requirements;
}
~
This method can be called for example by the check method, but additionally the idea of the proposal is to be called when reading a mdpa file or in the solver, and add the missing dofs/variables/properties and everything we can think of. The good thing of using Parameters on this method is than in the future we can extend it to any need, the bad thing is that Parameters is a heavy object, but if we do only once per element is not so bad.
The origin of this was the need to put on the Parameters "requires_rotation_dofs" when using shells or beams.
@KratosMultiphysics/implementation-committee @KratosMultiphysics/technical-committee
BTW @philbucher this can be used in order to create the database you would like to create for the interface automatically #4773
The @KratosMultiphysics/implementation-committee thinks that this is a useful idesa that would simplify some code and also bring robustness in some cases due to it's utility in implementing automatic addition of variables from the pyhton solver. However there are still some concerns regarding the efficiency and the generalization fot his concept to other types of objects.
Please correct me if I'm wrong, but in order to be capable to call this method, you need to at least have one element or condition already created, meaning that its nodes have been also created.
Thus, you will need to add variables on the fly, after having created some nodes, or to do some weird manipulation of the nodal variable data value container.
Am I wrong?
well, you have the prototype elements...
On Thu, Jun 27, 2019, 8:25 PM Rubén Zorrilla notifications@github.com
wrote:
Please correct me if I'm wrong, but in order to be capable to call this
method, you need to at least have one element or condition already created,
meaning that its nodes have been also created.Thus, you will need to add variables on the fly, after having created some
nodes, or to do some weird manipulation of the nodal variable data value
container.Am I wrong?
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
https://github.com/KratosMultiphysics/Kratos/issues/5093?email_source=notifications&email_token=AB5PWELFGEYSKZ4MZZDNFILP4UA2JA5CNFSM4HYRRPRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYX7CBA#issuecomment-506458372,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB5PWEOXPBFG5QOLMCIAAD3P4UA2JANCNFSM4HYRRPRA
.
well, you have the prototype elements...
I was going to reply that. Imagine that you create a specific method on the ModelPartIO that will be run before the actual read of the *.mdpa file. The objective of this method will be to find the "Element" and "Condition" declarations, so you can use with this the KratosComponents as @RiccardoRossi suggested. Some prototype:
~~~cpp
std::vector
... Fast read of mdpa to find the elements keys and fill name_of_elements_found_mdpa
// Now we fill the list of required variables
std::vector
for (auto& r_element_name : name_of_elements_found_mdpa) {
const auto& r_element = KratosComponents
const auto requirements_parameters = r_element.GetRequirements(r_process_info);
if (requirements_parameters.Has("required_variables")) {
const auto& r_var_pararameters = requirements_parameters["required_variables"];
required_variables.reserve(required_variables.size());
for (auto it_param = r_var_pararameters.cbegin(); it_param < r_var_pararameters.cend(); ++it_param) {
required_variables.push_back(it_param->GetString());
}
}
}
~~~
well, you have the prototype elements...
So you get the element from the KratosComponents to call the method? Is this what you mean?
well, you have the prototype elements...
So you get the element from the KratosComponents to call the method? Is this what you mean?
@rubenzorrilla see my comment
well, you have the prototype elements...
So you get the element from the KratosComponents to call the method? Is this what you mean?
@rubenzorrilla see my comment
Sorry, the internet connection in the place I'm now is not working so well (I wrote the comment before you posted your yours).
In any case, after @RiccardoRossi 's comment I was thinking in something similar to what you propose. I think that this approach could do the job. Would be nice to extend it to utilities and processes as well.
Indeed, in fact my idea was to make it work in a similar way to the Check, so it can be added in all levels.
In this case I would create an Info or Specification method which returns not only the requirments but also the info that we have in our XML files:
~cpp
Parameters Info(const ProcessInfo& rProcessInfo) const override
{
const Parameters element_info = Parameters("{
"required_variables" : ["DISPLACEMENT_X", "DISPLACEMENT_Y", "DISPLACEMENT_Z"],
"required_dofs" : ["DISPLACEMENT_X", "DISPLACEMENT_Y", "DISPLACEMENT_Z"],
"flags_used" : ["BOUNDARY", "ACTIVE"],
"compatible_geometries" : ["Tetrahedra3D4", "Hexahedra3D8"]
"compatible_constitutive_laws" : {
"type" : ["PlaneStress","PlaneStrain"],
"dimension" : "2D",
"strain_size" : "3"
}
}");
return element_info;
}
~
This can be very handy in creating a proper element factory.
This can be very handy in creating a proper element factory.
This is basically the idea, the name Info() fits better <3
I like the idea, but i think that "Info" is already used.
why do we need to pass the ProcessInfo btw?
I like the idea, but i think that "Info" is already used.
why do we need to pass the ProcessInfo btw?
Just in case
I like the idea, but i think that "Info" is already used.
Yes, Info is used, but returning std::string, not Parameters
to my understanding you cannot distinguish functions by the return type
to my understanding you cannot distinguish functions by the return type
You have a ProcessInfo as input 👀
I like the idea, but i think that "Info" is already used.
You are right! We may just change its usage (as it is not used extensively in elements) or we can use Specifications or any other suggested name.
'Specifications' seems much more appropriate than 'Info'!
ping @philbucher @rubenzorrilla What is the state of this issue?
I created #5608 with a first proposal
Most helpful comment
In this case I would create an
InfoorSpecificationmethod which returns not only the requirments but also the info that we have in our XML files:~cppParameters Info(const ProcessInfo& rProcessInfo) const override
{
const Parameters element_info = Parameters("{
"required_variables" : ["DISPLACEMENT_X", "DISPLACEMENT_Y", "DISPLACEMENT_Z"],
"required_dofs" : ["DISPLACEMENT_X", "DISPLACEMENT_Y", "DISPLACEMENT_Z"],
"flags_used" : ["BOUNDARY", "ACTIVE"],
"compatible_geometries" : ["Tetrahedra3D4", "Hexahedra3D8"]
"compatible_constitutive_laws" : {
"type" : ["PlaneStress","PlaneStrain"],
"dimension" : "2D",
"strain_size" : "3"
}
}");
return element_info;
}
~
This can be very handy in creating a proper element factory.