Discussion Closed This discussion was created more than 6 months ago and has been closed. To start a new discussion with a link back to this one, click here.
[Structral 3.5a] How do you validate your models ?
Posted 21.09.2009, 04:42 GMT-4 3 Replies
Please login with a confirmed email address before reporting spam
Hello everybody
First, I would suggest that we all start our subject line with a short summary of the application mode and the version we use or to which we relate our discussion, this would help us others to sort things and to give better replies.
Either by mentioning the specific application mode i.e [smsld 3.5a], or at least the global title in the subject line, knowing that the more precise we are more and better replies we could expect.
" Can we all survive with this ? "
Back to my specific question, (by the way Niklas I'm sure you are out here reading our comments, this could also be a subject for your Blog) :
-------------
I'm interesting to know and to exchange means how you verify and validate your structural models, how are you sure that the model is set up correctly?
Aspects such as: no over-constrained BC's, you are asking for sufficient many modes, i.e. not overlooking something, then only you might "solve" and validate your model against your measurements.
-------------
Update: following NAFEMS definition see:
www.nafems.org/downloads/working_groups/amwg/4pp_nafems_asme_vv.pdf
Definitions: for me "verification" of the model is checking that I'm coherent with the physics and I'm respecting the global hypothesis and limitations of the application mode. I start with this even before I solve the model. Thereafter, I "validate" my model that is: I compare my solved model results with my measurements to check that my "validated and solved model" is truly representative of my existing device being modelled.
The COMSOL documentation talks about how to do multiphysics for the Scientists, I'm still searching the specific chapter(s) on model verification methodology for us Engineers ;)
========
My first steps are systematically:
upd: 0) I import generally my CAD geometries from SolidWorks or another CAD tool to have independent volume, mass, centre of gravity (CoG) and inertia tensor calculations.
1) set up the model, the BC's, the material etc, mesh it and solve for "Get Initial Values" (just to fill the matrices).
2) check the mass against my CAD model values by: "Postprocessing Subdomain Integration" insert the density expression "rho_smsld" (or whatever application mode you use, but if you have several you must make a global variable i.e. "rho_all" and set it (Options Expressions Subdomain Expressions) and give the specific densities for the different subdomains, respectively shell, beam ... domains and do not forget any masses added to specific "points", if applicable). Then select all subdomains and "apply".
My tolerance here is typically < 5% difference, but mostly I'm around 1% or lower.
3) check the Inertia tensor against my CAD model values by "Postprocessing Geometric Properties", insert (again) the density expression "rho_smsld" (or whatever ... as above) ).
My tolerance here is typically < 5% difference, but mostly I'm around 1% or lower here too
Often you have to play with the coordinate system in the CAD, as COMSOL does not allow you to choose any coordinate system for the inertia, its all in the default coordinate system, w.r.t. the CoG (would be easy to update though in COMSOL).
4) Check the CoG, (and total Volume and Surfaces if applicable) here too I expect < 1% difference, otherwise I have misplaced a material or my meshing is so gross that I have lost significant items.
Note: the beam and shell modes do no allow you to calculate by COMSOL directly the inertia; you must go back to the subdomain integration and apply the full inertia formulas, just as if you want the results for a specific coordinate system).
5) I run a modal eigenfrequency analysis over the first >6 modes, none should be close to 0 Hz (typically none <1Hz if I expect my model to be fully constrained in 3D)
By the way, an additional question: how many modes to consider, how to, in COMSOL without any mass participation factors available, should one decide that most relevant modes stop at X Hz or after N modes ?
upd: 6) Static load check: by applying an acceleration of 1m/s^2 in x,y,z one should get reaction forces corresponding to the total mass of the model.
7) required for thermal analysis, but I mostly do it systematically: I go to the Subdomain Settings, I select all subdomains and set the thermal expansion to the same value i.e. 1.2E-5 [m/m/K], then in the "Load" tab I set include thermal expansion and put 100°C temperature difference between "Temp" and "Tempref". I solve and check the stress build-up, there should be none if my model is correctly constrained.
Typical tolerance: strain energy < 1e-3 [J].
8) ... more for specific needs, but let’s stop here, just now, and get your feedback.
Now I'm finally ready to solve, analyse my results and to validate my model.
========
What about your ways?
Expecting to read you soon
Ivar
First, I would suggest that we all start our subject line with a short summary of the application mode and the version we use or to which we relate our discussion, this would help us others to sort things and to give better replies.
Either by mentioning the specific application mode i.e [smsld 3.5a], or at least the global title in the subject line, knowing that the more precise we are more and better replies we could expect.
" Can we all survive with this ? "
Back to my specific question, (by the way Niklas I'm sure you are out here reading our comments, this could also be a subject for your Blog) :
-------------
I'm interesting to know and to exchange means how you verify and validate your structural models, how are you sure that the model is set up correctly?
Aspects such as: no over-constrained BC's, you are asking for sufficient many modes, i.e. not overlooking something, then only you might "solve" and validate your model against your measurements.
-------------
Update: following NAFEMS definition see:
www.nafems.org/downloads/working_groups/amwg/4pp_nafems_asme_vv.pdf
Definitions: for me "verification" of the model is checking that I'm coherent with the physics and I'm respecting the global hypothesis and limitations of the application mode. I start with this even before I solve the model. Thereafter, I "validate" my model that is: I compare my solved model results with my measurements to check that my "validated and solved model" is truly representative of my existing device being modelled.
The COMSOL documentation talks about how to do multiphysics for the Scientists, I'm still searching the specific chapter(s) on model verification methodology for us Engineers ;)
========
My first steps are systematically:
upd: 0) I import generally my CAD geometries from SolidWorks or another CAD tool to have independent volume, mass, centre of gravity (CoG) and inertia tensor calculations.
1) set up the model, the BC's, the material etc, mesh it and solve for "Get Initial Values" (just to fill the matrices).
2) check the mass against my CAD model values by: "Postprocessing Subdomain Integration" insert the density expression "rho_smsld" (or whatever application mode you use, but if you have several you must make a global variable i.e. "rho_all" and set it (Options Expressions Subdomain Expressions) and give the specific densities for the different subdomains, respectively shell, beam ... domains and do not forget any masses added to specific "points", if applicable). Then select all subdomains and "apply".
My tolerance here is typically < 5% difference, but mostly I'm around 1% or lower.
3) check the Inertia tensor against my CAD model values by "Postprocessing Geometric Properties", insert (again) the density expression "rho_smsld" (or whatever ... as above) ).
My tolerance here is typically < 5% difference, but mostly I'm around 1% or lower here too
Often you have to play with the coordinate system in the CAD, as COMSOL does not allow you to choose any coordinate system for the inertia, its all in the default coordinate system, w.r.t. the CoG (would be easy to update though in COMSOL).
4) Check the CoG, (and total Volume and Surfaces if applicable) here too I expect < 1% difference, otherwise I have misplaced a material or my meshing is so gross that I have lost significant items.
Note: the beam and shell modes do no allow you to calculate by COMSOL directly the inertia; you must go back to the subdomain integration and apply the full inertia formulas, just as if you want the results for a specific coordinate system).
5) I run a modal eigenfrequency analysis over the first >6 modes, none should be close to 0 Hz (typically none <1Hz if I expect my model to be fully constrained in 3D)
By the way, an additional question: how many modes to consider, how to, in COMSOL without any mass participation factors available, should one decide that most relevant modes stop at X Hz or after N modes ?
upd: 6) Static load check: by applying an acceleration of 1m/s^2 in x,y,z one should get reaction forces corresponding to the total mass of the model.
7) required for thermal analysis, but I mostly do it systematically: I go to the Subdomain Settings, I select all subdomains and set the thermal expansion to the same value i.e. 1.2E-5 [m/m/K], then in the "Load" tab I set include thermal expansion and put 100°C temperature difference between "Temp" and "Tempref". I solve and check the stress build-up, there should be none if my model is correctly constrained.
Typical tolerance: strain energy < 1e-3 [J].
8) ... more for specific needs, but let’s stop here, just now, and get your feedback.
Now I'm finally ready to solve, analyse my results and to validate my model.
========
What about your ways?
Expecting to read you soon
Ivar
3 Replies Last Post 03.03.2020, 15:28 GMT-5
Please login with a confirmed email address before reporting spam
Posted:
2 decades ago
My first step is always to check the dimensions and "fit" of the model, especially if I import geometry. I use swept meshes quite a bit, and they help a lot in this process - since they can get rather vocal whenever they hit even a small inconsistency.
Then, I write the expressions and variables. I tend to use several spaces and define every variable, to reduce the possibility of a small error in a complex equation. Once that is done, I get initial values using variables I define to check how they're being evaluated.
Once that is done, I make heavy use of groups in the subdomain/boundary/point conditions, checking everything several times, and again get initial values to check how internal variables are being evaluated.
Then I recheck the mesh for quality (both in the statistics and by going over the model to make sure that the resolution is correct for the part.
I work a lot with pressures on structures generated by fluids. Thankfully, the mexican federal comission of electricity has a very accurate set of models and guidelines for this (yes, that sounds incredibly odd, but they use it a lot for calculating wind loads on towers and structures, as well as for hydro power generation). It's actually the de facto normative in a good part of Mexico. So, I solve for simple scenarios (say, constant flow velocity or something like that), and check against the manual's expected values. Usually, under 5% to 10% deviation is normal, but up to 15% might be acceptable depending on circumstances (After all, we're dealing with formulas and simplifications vs. a detailed FEM model).
If it's not applicable, then I do a similar process with an simpler loading condition against theoretical results. If it's too complex to use formulas, I go over to tables. Thankfully, in my line of work, there are a couple sets of tables for most of what I do. If not, then we have a rather complete library of physical test results (all of our products must go through some very extensive physical testing, not just of the part, but of common assembly configurations).
If I'm going to define the pressures generated as equations instead of doing a fluid-structure interaction analysis (which is impossible for some of the most complex models), then I do a FSI analysis and a equation-based one over simpler loading conditions to check that there results are congruent.
Once I have this, then I stard adding complexity to the model, and solve. We have a couple of other FEM packages (though they're less powerful, since they're the licenses we've had before COMSOL). If they can handle it, I put it through them, too.
Lastly, common sense applies. Along with another engineer who is familiar with the problem (but who hasn't worked on the model, preferrably, so he has no preconceptions of what COMSOL should be doing) we go over the results, to see if they're consistent with expected behavior. We check to see if (for example) stress peaks are real stress concentrations or if they are issues with modeling.
That's about it. Of course, I'm describing it conversationally, so it might sound a little more haphazard than it actually is.
Then, I write the expressions and variables. I tend to use several spaces and define every variable, to reduce the possibility of a small error in a complex equation. Once that is done, I get initial values using variables I define to check how they're being evaluated.
Once that is done, I make heavy use of groups in the subdomain/boundary/point conditions, checking everything several times, and again get initial values to check how internal variables are being evaluated.
Then I recheck the mesh for quality (both in the statistics and by going over the model to make sure that the resolution is correct for the part.
I work a lot with pressures on structures generated by fluids. Thankfully, the mexican federal comission of electricity has a very accurate set of models and guidelines for this (yes, that sounds incredibly odd, but they use it a lot for calculating wind loads on towers and structures, as well as for hydro power generation). It's actually the de facto normative in a good part of Mexico. So, I solve for simple scenarios (say, constant flow velocity or something like that), and check against the manual's expected values. Usually, under 5% to 10% deviation is normal, but up to 15% might be acceptable depending on circumstances (After all, we're dealing with formulas and simplifications vs. a detailed FEM model).
If it's not applicable, then I do a similar process with an simpler loading condition against theoretical results. If it's too complex to use formulas, I go over to tables. Thankfully, in my line of work, there are a couple sets of tables for most of what I do. If not, then we have a rather complete library of physical test results (all of our products must go through some very extensive physical testing, not just of the part, but of common assembly configurations).
If I'm going to define the pressures generated as equations instead of doing a fluid-structure interaction analysis (which is impossible for some of the most complex models), then I do a FSI analysis and a equation-based one over simpler loading conditions to check that there results are congruent.
Once I have this, then I stard adding complexity to the model, and solve. We have a couple of other FEM packages (though they're less powerful, since they're the licenses we've had before COMSOL). If they can handle it, I put it through them, too.
Lastly, common sense applies. Along with another engineer who is familiar with the problem (but who hasn't worked on the model, preferrably, so he has no preconceptions of what COMSOL should be doing) we go over the results, to see if they're consistent with expected behavior. We check to see if (for example) stress peaks are real stress concentrations or if they are issues with modeling.
That's about it. Of course, I'm describing it conversationally, so it might sound a little more haphazard than it actually is.
Please login with a confirmed email address before reporting spam
Posted:
2 decades ago
Hi
Thanks for the precisions. I must apologise for having exchanges, in my initial page "validation" and "verification" w.r.t. NAFEMS approach, So I have corrected the page to follow NAFEMS definition, with a shortcut to their excellent 4 page summary.
Your comments made me also add a point "upd 0)" in my procedure above, to make it hopefully clearer. And I added the "static load check" see point "upd 6)" that I had forgotten.
I appreciate to see that other too go systematically through their models. Now, what about reference documentation/procedures on how to validate your model ? I'm, working often for ESA and ESO or related projects, the former has very strict procedures, see
www.ecss.nl
see "ECSS-E-30Part2A" of 25 april 2000, or the newer "ECSS-E-ST-32-03C" of 31 July 2008
and a few are difficult to check in COMSOL, therefore, I have to run my models still partially in NASTRAN and fully in COMSOL. The difficulty is mainly for the eigenmode "mass participation" factors in structural mode. COMSOL's eigenmode normalisation is different from NASTRAN's and does not allow a direct comparison between the modes, at least I haven’t found the quick-systematic way yet.
Are some of your Mexican reference documentation/procedures in the public domain, accessible through the web ? (even in Spanish, today we all have to read several languages, no?)
===========
How do you handle the selection of eigenmodes, and how do you (all out there) decide when you have studied all relevant modes, let’s say those representing >80% of the energy ?
COMSOL normalises this way: "COMSOL Multiphysics normalizes the eigensolutions so that their discrete root-mean-square norm is 1, ..." page 403 "Guide.pdf" for V3.5a
For me this means that each mode is normalised w.r.t. to itself, I cannot compare them. It's true that Comsol support proposed that I define a subdomain integration constant C = sqrt(u^2+v^2+w^2) and then normalise the mode shapes over 1/C, but I understand this still as an individual mode normalisation. NASTRAN and ANSYS normalises the eigenmode stiffness to 1 and then get the corresponding mass matrix with the modes relative participation in a global way.
One could also say that the integration of "int 0.5*rho*(u^2+v^2+w^2) dxdydz" for a given mode shape "i" is an expression for its energy but to be able to compare modes w.r.t. each other, and to all modes, this must be globally normalised.
I have been discussion this for some time with "Comsol support" I'm sure COMSOL will propose updates here in the near future, perhaps even in V4, but I'm getting impatient, and I believe this is also of interest to other out there.
Any further comments ?
Ivar
Thanks for the precisions. I must apologise for having exchanges, in my initial page "validation" and "verification" w.r.t. NAFEMS approach, So I have corrected the page to follow NAFEMS definition, with a shortcut to their excellent 4 page summary.
Your comments made me also add a point "upd 0)" in my procedure above, to make it hopefully clearer. And I added the "static load check" see point "upd 6)" that I had forgotten.
I appreciate to see that other too go systematically through their models. Now, what about reference documentation/procedures on how to validate your model ? I'm, working often for ESA and ESO or related projects, the former has very strict procedures, see
www.ecss.nl
see "ECSS-E-30Part2A" of 25 april 2000, or the newer "ECSS-E-ST-32-03C" of 31 July 2008
and a few are difficult to check in COMSOL, therefore, I have to run my models still partially in NASTRAN and fully in COMSOL. The difficulty is mainly for the eigenmode "mass participation" factors in structural mode. COMSOL's eigenmode normalisation is different from NASTRAN's and does not allow a direct comparison between the modes, at least I haven’t found the quick-systematic way yet.
Are some of your Mexican reference documentation/procedures in the public domain, accessible through the web ? (even in Spanish, today we all have to read several languages, no?)
===========
How do you handle the selection of eigenmodes, and how do you (all out there) decide when you have studied all relevant modes, let’s say those representing >80% of the energy ?
COMSOL normalises this way: "COMSOL Multiphysics normalizes the eigensolutions so that their discrete root-mean-square norm is 1, ..." page 403 "Guide.pdf" for V3.5a
For me this means that each mode is normalised w.r.t. to itself, I cannot compare them. It's true that Comsol support proposed that I define a subdomain integration constant C = sqrt(u^2+v^2+w^2) and then normalise the mode shapes over 1/C, but I understand this still as an individual mode normalisation. NASTRAN and ANSYS normalises the eigenmode stiffness to 1 and then get the corresponding mass matrix with the modes relative participation in a global way.
One could also say that the integration of "int 0.5*rho*(u^2+v^2+w^2) dxdydz" for a given mode shape "i" is an expression for its energy but to be able to compare modes w.r.t. each other, and to all modes, this must be globally normalised.
I have been discussion this for some time with "Comsol support" I'm sure COMSOL will propose updates here in the near future, perhaps even in V4, but I'm getting impatient, and I believe this is also of interest to other out there.
Any further comments ?
Ivar
Please login with a confirmed email address before reporting spam
Posted:
5 years ago
Updated:
5 years ago
This thread looks like a good place to promote the Verification and Validation Models page COMSOL recently added to our website. It gathers well over a hundred verification and validation models and their documentation.
Models can be filtered by discipline or by module, as well as searched through via a free word search. Those models cover a wide range of physical phenomena and include checks again analytical solutions, semi-analytical solutions, solutions obtained by other numerical methods, experimental data reported in the literature, etc...
Best,
Jeff
-------------------Jeff Hiller