I thought I would go ahead to try simulating with the mesh I got at 13 layers… just to see how it goes. But my simulation is blowing up. Just wanna ask a few questions to make sure it is not blowing up because I am setting something wrong (i.e. it is due to poor mesh quality):
I followed pretty much what I can see from FiliptheKing’s.
I did amend the air density and viscosity to represent the design conditions of the propeller (eg. flight altitude)
Now, for the pressure setting in the initial conditions, it is a gauge pressure, which I understand to mean it references another setting. This setting, I thought to be “Pressure reference value” under Numerics. However, I saw this to be set to 0 Pa for FiliptheKing’s. Should this be the flight altitude pressure? And then the initial condition (gauge) pressure value will be 0 Pa.
For pressure outlet, I set it as 0 Pa.
Does these sound about right? Most wanted to clarify #3.
The problem with using STL is that I was only able to generate the propeller geometry and not the surrounding volume for MRF. Haven’t got around to trying… does anyone know if I can use a geometry primitive for the surrounding volume for MRF, AND one for the outer farfield boundaries?
Looks pretty good. I’ve been exploring cfMesh and attempting to mesh the other topic where Dale and others were discussing. That geometry is giving me issues so I think I will move on yours and attempt to run it through cfMesh to see if I can get a better quality.
I don’t believe you can use the geometry primitive. Not exactly sure though. I’ve always generated my MRF volume through CAD.
As for the outer farfield boundaries, that should be possible as it is effectively just the bounding box.
Alright, so the mesh from the STL really does look good after I did a couple more cross-sections. However, this is infuriating as I am trying to do a MRF and so I need another volume around it for the MRF. After experimentation, I do need this volume to be imported together in the CAD, which unfortunately 2 solids, with 1 inside the other, is not compatible with STL! ARGH. @jousefm or anyone at SimScale able to help here???!
I did another based on STEP geometry, it was good too but not as good as the STL one. i.e. the prism layers did not form as comprehensively as the STL one.
So, it seems for me, in terms of prism layer formation percentage
STL > STEP > IGES
for imported CAD geometry format. Will post some pictures tomorrow.
@cweisheng: I use near exclusively STL for my geometries, 80% of them have defined MRF volume, rotor, propeller or whatever being inside and never had problem with it. Why it would be incompatible, please?
I guess I would like to ask which CAD software you are using, and how do you export both geometries, the rotor and the MRF volume as one STL (or not, and if not, how do you import and work into SimScale)? Would it be possible to share your workflow in some detail? I am sure it is just my ignorance.
I would be interested to know the workflow for generating a MRF volume in STL as well. Snappy and cfMesh both prefer the STL format (though cfMesh does like another format called fms) so knowing how to generate it would be great.
@Get_Barried and @cweisheng: take a look at one of geometry I use in Magnus effect Project:
Geometry: CylRotSlim
Simulation: CylRotMenium
Geometry contains ‘solid_0’ composed with ‘ascii’ and ‘ascii_1’ bodies. MRF zone definition is as near as possible to rotating body.
I did filetted the edges to avoid high gradients with air moving (shear) in standing still air (whole BMB).
Now, I did it in Fusion, with ‘export’ to STL. This is old Fusion and I cannot tweak the resolution of STL mesh there.
@cweisheng you can export / import that geometry to you CAD tool and see how your CAD will handle those bodys. Switch the visibility of one or another, you should be able to handle it without problem.
Above, second element ‘Facet normal’ belongs to another part.
First part stops with first ‘Facet normal’ element.
There is no name attribute to separate both parts. So possibly no way to discover different parts while parsing that text file. Too bad.
You can export those parts in separate files: final format is in ZIP. Than I would need to write a script to merge those parts in one STL file, with elements attributes indicating different names.
The current work around to STL file merging intersecting geometry is simply concatenate them (text files). You can also , in text editor, edit name of the solid;
solid Blurb
facet normal 1.632797e-002 -1.240232e-001 -9.921450e-001
Above I replaced ‘ascii’ with ‘Blurb’. Simscale will respect it. If all solids are named ‘ascii’, Simscale will increment the name with ‘_1, _2, …’.
That sounds very smart! I guess what you are saying is to combine 2 STL files, each with 1 of the Solids…
Ok, I just need to find out how to do that as I am not familiar with the process you mentioned. But thanks!
Edit:
awesome. previously i was saving as binary so the file was not readable. but i saw the ascii option and that is readable (in notepad++)
so i did as i think you meant, i appended one file (with one solid) to the other (with the other solid) and renamed them
i checked them in Fusion and I do see 2 bodies
I imported them into SimScale - it was one solid but 2 i-dont-know-what (faces?) that i was able to select for meshing based on mrf and propeller. it’s meshing now… so fingers crossed. still, great hack! will update if it works.
Great! Notepad++ is the best for manual concatenations of text files. By the way: MRF zone should be really in the vicinity of the propeller. Do not make it too big.
If it is a solution for your problem, please indicate it were appropriate.
Hi all, so yes, this post is to confirm that using STL exclusively seems to result in higher prism layer formation! Thanks again @Retsam
Details:
Objective of my current exploration was to conduct MRF simulation on propeller to see how well SimScale predicts the thrust and torque characteristics. Before I can do that, a decent simulation mesh needs to be generated and this post was a result of problems encountered at this stage.
As you would read above, there were several problems along the way, perhaps due to my inexperience with OpenFoam and SnappyHex. All along, I was working with IGES files and the best prism layer formation was about ~70% I would say (optimistically). I have tried both y+=1 and y+=100 types, 5 layers to >10 layers etc since the cause of the problems were not clear.
After almost giving up, and with very few options left (haven’t tried cfmesh as I don’t think my laptop has enough RAM), I just thought of trying STL. But I was not able to import 2 solids in 1 file if I directly output from Autodesk Fusion360. Nevertheless, the prism layer formation was >90% for meshing without the MRF volume.
Luckily @Retsam replied my distress call on STL and I managed to combine 2 STL files by exporting them in ASCII format and copying and pasting one STL file to another using Notepad++. Great idea! You will have something like that:
solid PROPELLER [this is the 1st STL file]
facet normal -8.195655e-01 5.663210e-01 8.713685e-02
outer loop
vertex -1.877391e+01 1.240122e+01 8.000000e+00
vertex -1.874856e+01 1.238448e+01 8.347296e+00
vertex -1.796457e+01 1.354920e+01 8.151286e+00
endloop
.
.
.
endsolid
solid MRFVOLUME [this is the pasted-in 2nd STL file]
.
.
.
endsolid
And then save as “All Files” with the .STL extension. Then proceed to import into SimScale.
With the MRF volume inside too, it works! Again, >90% of the prism layers generated:
solid_0_PROPELLER 297213 9.97 0.000308 92.7
I used very fine tessellation on the propeller (and reminder to self to scale down by 0.001 to work in m).
Your welcome! However credits should go to @Get_Barried, @anirudh2821998 as topic is about meshing. I simply took a look at STL file handling, which is nothing compared to meshing complexity!
Different geometry, same problem (if not worse). Now, even the high y+ mesh PL is problematic (0.2% formed), following all the previous settings and tricks.
SimScale sales contacted me to ask about converting to Professional plan… no news heard after I shared the pain points.
Jousef, I wanted to confirm, exporting as STL instead of importing directly fom Onshape is still the recommended path? It would be great if Simscale did this by itself
