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.
Imported SolidWorks part doesn't behave correctly
Posted 17 févr. 2013, 23:31 UTC−5 9 Replies
Please login with a confirmed email address before reporting spam
I'm relatively new to COMSOL but I haven't had much luck finding a solution.
I had an assembly in SolidWorks made of 3 parts. I created a new SolidWorks part file which had the 3 parts mated together correctly and saved it. I imported that SolidWorks part into COMSOL. COMSOL recognized it as having 3 domains which I assigned different material properties to. I fixed the bottom and applied a load on the top. When I ran a tetrahedral static solid model test, the stress was what I expected for the top layer but it appears that it did not make it to the remaining layers. The stress on one side of the interface is a magnitude different than the other side, right at the interface. I attached a picture of this.
The nodes seem to align at the interface too. Even when I used the same mesh size for the entire model, I had the same issue. Does anyone have suggestions on a solution? I also attached my setup.
I can provide more detail and pictures if needed.
Thanks,
Jeremy
I had an assembly in SolidWorks made of 3 parts. I created a new SolidWorks part file which had the 3 parts mated together correctly and saved it. I imported that SolidWorks part into COMSOL. COMSOL recognized it as having 3 domains which I assigned different material properties to. I fixed the bottom and applied a load on the top. When I ran a tetrahedral static solid model test, the stress was what I expected for the top layer but it appears that it did not make it to the remaining layers. The stress on one side of the interface is a magnitude different than the other side, right at the interface. I attached a picture of this.
The nodes seem to align at the interface too. Even when I used the same mesh size for the entire model, I had the same issue. Does anyone have suggestions on a solution? I also attached my setup.
I can provide more detail and pictures if needed.
Thanks,
Jeremy
Attachments:
9 Replies Last Post 4 mars 2013, 12:27 UTC−5
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Jeremy-
Interesting issue...
Would you be able to upload your mph file? To save space you can click Edit>Clear Meshes and Edit>Clear Solutions before uploading.
Regards,
Josh Thomas
AltaSim Technologies
Interesting issue...
Would you be able to upload your mph file? To save space you can click Edit>Clear Meshes and Edit>Clear Solutions before uploading.
Regards,
Josh Thomas
AltaSim Technologies
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Yes I can. I'm not sure if you need the .sldprt file with it to open. The file is too large and I'm not currently at a computer to resave the .mph file. Does it violate forum rules if I use WeTransfer to send the file? I can PM it if necessary.
Jeremy
Jeremy
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
You don't need the CAD file once it's imported and saved as an mph. I'd recommend waiting until you are able to upload the mph file.
Regards,
Josh
Regards,
Josh
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Here is the .mph file without mesh or results.
Jeremy
Jeremy
Attachments:
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Jeremy-
Common mistake that is easy to make: You have part of the interface between the top and middle layer accidently defined as a symmetry boundary. See attached screen shot. These mistakes are hard to spot when boundaries are opaque. In the future, I would recommend checking all b.c.s using the wireframe mode.
Also, unless you are running non-axisymmetric loading conditions in the future. I would highly recommend running this model as 2D axisymmetric. You will get a huge savings in memory and not lose any information.
Also, if you do want/need to run the 1/4 symmetry. You can probably decrease the mesh resolution. At least for debugging purposes so you aren't running 6 million DoF until you absolutely need to.
Best regards,
Josh
Common mistake that is easy to make: You have part of the interface between the top and middle layer accidently defined as a symmetry boundary. See attached screen shot. These mistakes are hard to spot when boundaries are opaque. In the future, I would recommend checking all b.c.s using the wireframe mode.
Also, unless you are running non-axisymmetric loading conditions in the future. I would highly recommend running this model as 2D axisymmetric. You will get a huge savings in memory and not lose any information.
Also, if you do want/need to run the 1/4 symmetry. You can probably decrease the mesh resolution. At least for debugging purposes so you aren't running 6 million DoF until you absolutely need to.
Best regards,
Josh
Attachments:
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
>Common mistake that is easy to make: You have part of the interface between the top and middle layer accidently defined as a symmetry boundary. See attached screen shot. These mistakes are hard to spot when boundaries are opaque. In the future, I would recommend checking all b.c.s using the wireframe mode.
Thank you Josh! I did this setup two times and I must have made the same mistake twice. I will switch to wire frame next time.
>Also, unless you are running non-axisymmetric loading conditions in the future. I would highly recommend running this model as 2D axisymmetric. You will get a huge savings in memory and not lose any information.
The plan was eventually to run models that were only axisymmetric in quarters. For this model, I may try running it in 2D. Good suggestion.
>Also, if you do want/need to run the 1/4 symmetry. You can probably decrease the mesh resolution. At least for debugging purposes so you aren't running 6 million DoF until you absolutely need to.
I increased the mesh size to .2mm just for debugging.
When I ran the test again with those changes, I found that the stress jumps by 50% as soon as the interface is crossed. 95 MPa to 54 MPa. If the nodes at the interface are aligned correctly, I would expect the stress to be the same at the interface since they should share the same nodes. I also don't know of an easy way to find the stress at the nodes of the interface.
I attached "Comsol test" which is my COMSOL result and "Simulation" which is my analysis using a different FEA program.
Do you know why COMSOL's results don't match?
Thank you for the quick response,
Jeremy
Thank you Josh! I did this setup two times and I must have made the same mistake twice. I will switch to wire frame next time.
>Also, unless you are running non-axisymmetric loading conditions in the future. I would highly recommend running this model as 2D axisymmetric. You will get a huge savings in memory and not lose any information.
The plan was eventually to run models that were only axisymmetric in quarters. For this model, I may try running it in 2D. Good suggestion.
>Also, if you do want/need to run the 1/4 symmetry. You can probably decrease the mesh resolution. At least for debugging purposes so you aren't running 6 million DoF until you absolutely need to.
I increased the mesh size to .2mm just for debugging.
When I ran the test again with those changes, I found that the stress jumps by 50% as soon as the interface is crossed. 95 MPa to 54 MPa. If the nodes at the interface are aligned correctly, I would expect the stress to be the same at the interface since they should share the same nodes. I also don't know of an easy way to find the stress at the nodes of the interface.
I attached "Comsol test" which is my COMSOL result and "Simulation" which is my analysis using a different FEA program.
Do you know why COMSOL's results don't match?
Thank you for the quick response,
Jeremy
Attachments:
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Jeremy-
The FE formulation solves for displacements at the degrees of freedom (essentially the nodes). Strain depends on the displacements and stress = Young's modulus * strain (in a 1d sense). Therefore, displacements will be unique at any interfaces between materials. But, if you have an interface where Young's modulus (or Poisson's ratio) is different on either side of the interface. The stress in these materials will be different. So, the results you are seeing indeed make sense. Stress is not uniquely defined at the interface. For plotting and evaluation purposes, FE post-processing codes perform some interpolation of stresses to report values of stress at nodes.
If you evaluate stress at a node interface, you are actually evaluating an interpolated value (some average of the stresses from either side of the interface). Only the displacements will be continuous across the interface.
It's hard to comment on why the results differ for models built from two FEA packages. I would advise comparing displacements at specific node locations rather than stresses since stress evaluations at nodes (as well as plotting) requires interpolation schemes that may differ between packages and be the cause for local differences between your contour plots. This may be the cause for the difference. Other things to check -- are you including geometric non-linearity in both packages? Is the mesh equally refined? Do you have a follower load defined in the other package? All of these may be causes for differences.
Hope that helps some.
Regards,
Josh Thomas
AltaSim Technologies.
The FE formulation solves for displacements at the degrees of freedom (essentially the nodes). Strain depends on the displacements and stress = Young's modulus * strain (in a 1d sense). Therefore, displacements will be unique at any interfaces between materials. But, if you have an interface where Young's modulus (or Poisson's ratio) is different on either side of the interface. The stress in these materials will be different. So, the results you are seeing indeed make sense. Stress is not uniquely defined at the interface. For plotting and evaluation purposes, FE post-processing codes perform some interpolation of stresses to report values of stress at nodes.
If you evaluate stress at a node interface, you are actually evaluating an interpolated value (some average of the stresses from either side of the interface). Only the displacements will be continuous across the interface.
It's hard to comment on why the results differ for models built from two FEA packages. I would advise comparing displacements at specific node locations rather than stresses since stress evaluations at nodes (as well as plotting) requires interpolation schemes that may differ between packages and be the cause for local differences between your contour plots. This may be the cause for the difference. Other things to check -- are you including geometric non-linearity in both packages? Is the mesh equally refined? Do you have a follower load defined in the other package? All of these may be causes for differences.
Hope that helps some.
Regards,
Josh Thomas
AltaSim Technologies.
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Hi Josh,
Thank you for the thorough responses. I have been working with a couple people to understand my results.
This may be what you were saying but this is what we came up with:
If the model is graphed as Z tensor stress, the stress is fluid across the layers. In 1D, stress would be P/A.
With Von Mises, triaxial stresses as well as shear stresses are all factors. There are large radial stresses in my model, creating the stress "jump" which "looks" like a discontinuity.
I also switched to a 2D model which allowed me to make the mesh extremely fine for accuracy.
Thank you for your help.
Jeremy
Thank you for the thorough responses. I have been working with a couple people to understand my results.
This may be what you were saying but this is what we came up with:
If the model is graphed as Z tensor stress, the stress is fluid across the layers. In 1D, stress would be P/A.
With Von Mises, triaxial stresses as well as shear stresses are all factors. There are large radial stresses in my model, creating the stress "jump" which "looks" like a discontinuity.
I also switched to a 2D model which allowed me to make the mesh extremely fine for accuracy.
Thank you for your help.
Jeremy
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Hi Jeremy-
Yes. I see how the normal component of stress is indeed continuous across the material interface. But, the other components are not. Of course, in the real system every component of stress is going to be continuous. So the question is, why aren't we seeing this in the FE results?
You say that the other stress components only "look" discontinuous. As far as I understand, these components not only "look" discontinuous but indeed "are" discontinuous in the FE solution. This is a limitation of the element formulation which is based on displacements only. The FE formulation only enforces C^0 continuity of the dependent variable(s), in this case displacement. This means that the values of displacement will be continuous but the gradients of displacement are not necessarily going to be continuous. Strains and stresses are functions of displacement gradient. Therefore, the FE solution does not enforce stress continuity across the elements. As it turns out, for some components of stress as you refine the mesh you will get closer and closer to a continuous stress field. But, this is not the case for every component of stress on the interface.
If you research the topic of "interlaminar stress recovery" or "stress compatible bi-material interface" you will see that a lot of research goes into coming up with specialized element formulations that give a more accurate stress result at nodes that lie on interfaces between 2 materials. I don't believe COMSOL has implemented these elements yet, but I may be mistaken. In my experience, these highly specialized elements are only needed for niche applications such as layered composites and de-bonding strength calculations, etc.
Hope that explanation helps a little more than my previous post.
In all, it's an interesting observation you've made that gets at the heart of the numerical scheme.
Best regards,
Josh Thomas
AltaSim Technologies
Yes. I see how the normal component of stress is indeed continuous across the material interface. But, the other components are not. Of course, in the real system every component of stress is going to be continuous. So the question is, why aren't we seeing this in the FE results?
You say that the other stress components only "look" discontinuous. As far as I understand, these components not only "look" discontinuous but indeed "are" discontinuous in the FE solution. This is a limitation of the element formulation which is based on displacements only. The FE formulation only enforces C^0 continuity of the dependent variable(s), in this case displacement. This means that the values of displacement will be continuous but the gradients of displacement are not necessarily going to be continuous. Strains and stresses are functions of displacement gradient. Therefore, the FE solution does not enforce stress continuity across the elements. As it turns out, for some components of stress as you refine the mesh you will get closer and closer to a continuous stress field. But, this is not the case for every component of stress on the interface.
If you research the topic of "interlaminar stress recovery" or "stress compatible bi-material interface" you will see that a lot of research goes into coming up with specialized element formulations that give a more accurate stress result at nodes that lie on interfaces between 2 materials. I don't believe COMSOL has implemented these elements yet, but I may be mistaken. In my experience, these highly specialized elements are only needed for niche applications such as layered composites and de-bonding strength calculations, etc.
Hope that explanation helps a little more than my previous post.
In all, it's an interesting observation you've made that gets at the heart of the numerical scheme.
Best regards,
Josh Thomas
AltaSim Technologies