How about a general FemMaterial.py to suport Mechancial, Thermal, Fluidic and ElectroMagnetic

[bernd]

Does not the same problem exist with the fem analysis. also there are serval other analysis posible and also there are radio butons used...

You mean the CalculiX solver task panel, do you? For sure this needs some reimplemantation some time in the future too. Most solver properties can not be set. But thats another story of FreeCAD FEM.

[Jee-Bee]

You mean the CalculiX solver task panel, do you? For sure this needs some reimplemantation some time in the future too. Most solver properties can not be set. But thats another story of FreeCAD FEM.

Yes indeed the Calculix solver task panel... I try to stop mess thinks up...

[johan]

In light of the discussion above, I am trying to come up with an elegant way to keep the code as modular as possible and also solver independent, while still making sure it is intuitive for the CFD user (my FEM knowledge is very limited and it seems the FEM WB has a workable solution in place?). Current thinking is to create, similar to the FEM mat props, a data base with a long list of fluids (gasses and liquids) with their density, viscosity, thermal coeff, etc, but I am not sure how to align this with the OpenFOAM philosophy. I have two concerns:

1. It might make sense to have a couple of fluid properties at 20 degree C and 1 atm which the user can quickly use, but any point outside of this would have to be calculate using either empirical correlations of interpolated for a database. Although such a functionality would be useful in future, I think most CFD users are more than happy to quickly look up the mat prop.

2. Different analyses require different input parameters and I think it would be great if the user only have to specify the coefficients that are required the specified analysis. For example:
* Incompressible, isothermal flow - density & dynamic viscosity
* Bouyant Boussinesq - Density, viscosity, thermal expansion, Ref temp, Prantl etc.
* Compressible (non-isothermal) - Number of moles and molecular weight, thermodynamic info (eg. cp and h), transport properties are calc by solver (eg Sutherland eq).

* In terms of porous and multiphase flow, OpenFOAM does not really treat these as a multiregion analysis, but rather reuse the existing transport and thermophysical framework and merely specify an additional volume fraction field.

* The CHT (and potentially FSI) solvers require a multiregion implementation.

Form the user's perspective it may be useful to have a customised mat prop ui according to the selected analysis, but I am struggling to think of a elegant way of incorporate that into a generic ui.

[cox]

I do not know anything about the subject, but while reading your post @johan, it hit me that computer calculators solve this by having different modes. Simple, Scientific, programming etc.

[qingfeng.xia]

I like a combo box much more than the radio buttons for choosing the material type. New material types or categories could be added much more simpler than with new radio buttons. We could have electricity and many more material types in the future. The task panel should change with material category and only show the needed properties. Have a look at the beam section object task panel for example.

bernd

OK, We goes back to Combo box. Also tabwidget as in my last year demo could also make ui tidy.

I think we should make this class ui simple only for linear/constant properties.
regarding air/gas as incompressible fluid with constant properties is common in CFD, HT, which is true for Mach number <0.3, 100 m/s.
for viscosity, there are different models, also for density,

Electromagetic properties will not make a new category of material, fluid and solid all got: electronic resistance, magnetic permissivity, Dielectric Constant
http://services.eng.uts.edu.au/cempe/su ... et_ch3.pdf

If nonlinear material, like ideal gas model for compressible gas, I think it should goes into another takspanel as nonlinear (properties as a function of T) solid material Already in Fem. If gas can be easily expressed in a simple UI , it can into into femmaterialtaskpanel. in later stage. as the third material type. "IdealGas" ?

@johan

Compressible (non-isothermal) - Number of moles and molecular weight, thermodynamic info (eg. cp and h), transport properties are calc by solver (eg Sutherland eq).

Can we drop this support for this commit, it can be built into a new TASKpanel.

Material catogory could be renamed to avoid misunderstanding "LinearElasticsolid" instead of Solid? IncompressibleFluid, isntead of Fluid?

Can I propose, code that can be shard in FemMaterialTaskPanel, should be extract into FemMaterialTools.py for body selection and standard material load. so a wide range of nonlinear material can be implemented easily?

In Sum, we make a linear material to run simple FEA and CFD for the moment.

[makkemal]

@johan

In light of the discussion above, I am trying to come up with an elegant way to keep the code as modular as possible and also solver independent, while still making sure it is intuitive for the CFD user (my FEM knowledge is very limited and it seems the FEM WB has a workable solution in place?). Current thinking is to create, similar to the FEM mat props, a data base with a long list of fluids (gasses and liquids) with their density, viscosity, thermal coeff, etc, but I am not sure how to align this with the OpenFOAM philosophy. I have two concerns:

1. It might make sense to have a couple of fluid properties at 20 degree C and 1 atm which the user can quickly use, but any point outside of this would have to be calculate using either empirical correlations of interpolated for a database. Although such a functionality would be useful in future, I think most CFD users are more than happy to quickly look up the mat prop.

2. Different analyses require different input parameters and I think it would be great if the user only have to specify the coefficients that are required the specified analysis. For example:
* Incompressible, isothermal flow - density & dynamic viscosity
* Bouyant Boussinesq - Density, viscosity, thermal expansion, Ref temp, Prantl etc.
* Compressible (non-isothermal) - Number of moles and molecular weight, thermodynamic info (eg. cp and h), transport properties are calc by solver (eg Sutherland eq).

* In terms of porous and multiphase flow, OpenFOAM does not really treat these as a multiregion analysis, but rather reuse the existing transport and thermophysical framework and merely specify an additional volume fraction field.

* The CHT (and potentially FSI) solvers require a multiregion implementation.

Form the user's perspective it may be useful to have a customised mat prop ui according to the selected analysis, but I am struggling to think of a elegant way of incorporate that into a generic ui.

+1
Get the CFD workbench to the point that it is usable by anyone and then start building in details in the materials etc . If you spend too much time on this now the whole workbench is not going to be working soon.

[oliveroxtoby]

Hi all

We have been discussing this at some length and I am a bit concerned about going down the path of having a material selector that is separated from the CFD workbench.

Initially, I really liked the abstraction of a single unified material selector. However, as Johan pointed out, different solvers (incompressible, compressible, buoyant, etc) have very different input requirements in terms of material properties. Of course, it is possible to store all possible required parameters in the database of known materials, but what we are concerned about is when the user wishes to enter their own parameters - they will either have to enter dozens of parameters that are not used most of the time, or else the FEM material selector will have to communicate quite intimately with the CFD workbench to know what properties are required for the solver in use.

Different compressible and non-isothermal solvers have different ways of inputting the temperature dependence, for example - e.g. Sutherland's law and its associated coefficients, versus an arbitrary polynomial, etc etc.

I feel it would be more pragmatic to have the CFD workbench query the user for the relevant material properties depending on the type of analysis. Presets can always be loaded from a central database, of course.

If I'm not getting too carried away with philosophy here, I think the problem is that the required inputs for a material are governed more by the way it is solved in CFD rather than the type of material itself, as in FEM(?). So we are in danger of ending up with all kinds of hacks mixed in with the material selector to cater for the different types of CFD solvers.

Thanks
Oli

[johan]

If nonlinear material, like ideal gas model for compressible gas, I think it should goes into another takspanel as nonlinear (properties as a function of T) solid material Already in Fem. If gas can be easily expressed in a simple UI , it can into into femmaterialtaskpanel. in later stage. as the third material type. "IdealGas" ?

@johan

Compressible (non-isothermal) - Number of moles and molecular weight, thermodynamic info (eg. cp and h), transport properties are calc by solver (eg Sutherland eq).

Can we drop this support for this commit, it can be built into a new TASKpanel.

I do not grasp the motivation for creating a unified material selector which only allows for constant properties and then creating an additional TaskPanel for non-linear properties (non-isothermal flows)? I assume this might be useful in the FEM WB (eg when considering 1D pipe flows), but is this not only going to complicate things in the CFD WB?

[qingfeng.xia]

The movitation of unified material is for multiple physical modeling, thermal stress problem means thermal and mechanical properties are needed.
For eletronic heating induced stress, EM properties are needed.

For most of CFD, a simple incompressible fluid with constant density, viscosity is needed. Adding a property, viscosity into current FemMaterialTaslPanel, fluid material is supported without a series of new classes.

It is not easy to reach a agreement on how complex fluid material UI design. we just stop discussion here.

But there must be a widely recognized API on data/document/storage
1) How material properties should be stored in App:Material document object. Currently all properties is set in a dict property
2) How standard material should be stored. FreeCAD web promotes the XML file but it is not widely used.
3) how to deal with missing properties.

e.g. current solid std material, I hope properties can be grouped, if possible to detect if thermal properties are available
https://github.com/jaheyns/FreeCAD/blob ... 1C22.FCMat

Code: Select all

[FCMat]
Name = 1C22
NameDE = C22
Description = Case hardened alloy steel
DescriptionDE = kleiner Vergütungsdurchmesser, gut schweißbar
DescriptionPL = Stal stopowa do nawęglania
Father = Metal
YoungsModulus = 210000 MPa
UltimateTensileStrength = 400
PoissonRatio = 0.3
Density = 7800 kg/m^3
KindOfMaterial = Heat-treatable steel
KindOfMaterialDE = Vergütungsstahl
MaterialNumber = 1.0402
ModulusOfShare = 81000
Norm = EN 10083-1
ThermalExpansionCoefficient = 1.10E-005
UltimateStrain = 27
YieldStrength = 230

if we know how to distinguish diff type of material. we know how to retrieve properties. then, material can be shared between solver.

@Johan, please post your file content of standard FluidMaterial
I do hope your FluidMaterialTaskPanel can be commit to Fem. so is the std mat files into Mod/Material/Fluid/

BTW, can code of reference_selection can be extracted into a widget from femmaterialtestpanel, and reused. If not a widget, we can just reuse the several python functions.

Then everyone is free to reuse code to make new material task panel easier.

Thanks

[bernd]

We could move the reference shape selection into a separate object. Have a look at the GMSH mesh object and the mesh region object. The GMSH mesh object holds the properties for the whole mesh and the mesh region object defines them for special regions. It would be a bit different since we would allow only one material region object for each material which defines the regions for the material it belongs too.

If we have multiple task panels for different material types we need to decide if we would split the material object or if we just implement a multiple task panel which changes in the regard of material types but is one big ui file. As long as we stick to the material dictionary from App::MaterialObjectPython it makes sence not to split the material object and use a multiple task panel IMHO.

All the nonlinear material stuff which can not be saved inside the material dictionary of App::MaterialObjectPython should go into an own object.

Bernd