Could be, also, when I redrew your geometry I did not like the interface between the rounded cross tubes and the fins.
That intersection just smells bad for meshing…
Could be, also, when I redrew your geometry I did not like the interface between the rounded cross tubes and the fins.
That intersection just smells bad for meshing…
If you want a STEP file, I can give you a STEP file but I have lost my faith recently in them.
I have an open issue with them in the private PowerUser forum. (You could see that if you were a PU )
Also, you could much more easily see your surface mesh issues with a quick download of the mesh and in ParaView extract the surface like I showed above in my CyberTruck tread images
Use this trick to be able to view HEXpara meshes easily in ParaView
So i upped the fin edges to level 8. This helped significantly with the edge quality. However this larger view somewhat confirms my “edge between cells lining up with the geometry snap point” theory. Every other row where the fins meet has a worse snapping mesh. I think your geometry movement will help with this.
What i also find interesting is that this only seems to happen the worst as it reaches the outer edges of the fins. Not sure why on that one.
Either way Dale, i will try your geometry alignment method tomorrow, but this project in general is a “rabbit hole” for me. I really need to get back to my main goal with these simulations. However, i now feel much better equipped to resolve any snapping issues in my full car mesh.
Well, you know me by now…
I just had to proceed alone down my rabbit hole for now
I fairly easily determined that this is a GOOD rabbit hole
Here is a 90% layered mesh will ALL the inside corner issues resolved using a smaller CAD file section of my ‘snapped to Level 6 grid’ geometry and here is a ParaView image which shows the 90% layering in the Grey slice (at x=0.01m at 50% opacity) and it shows that all the inside corner crap is gone by looking at this parallel projection of the Colored Surface Grid:
Comments along the way:
You really should work with small geometry sections when testing out meshing on geometries like this. My small geometry only has 240 faces and this means the layer table in the meshing log snippet will be complete and let you analyze the layer %age. This one is 90% and I am sure you can improve on my quick set of 2 total refinements and default snap settings (but I did have to reduce Min Cell Volume to 1e-15) using your recent snapping experience. Using a smaller BMB does not work unless the BMB does not split a face that is layered and you select only the faces inside the BMB to have layered…
I have not tried but you should be able to capture the end of the ‘Layer addition iteration 0’ section so you can see what reason that Snappy is removing most of those 10% of layers it removes…
The only clumpy area of surface mesh cells now are the very sharp corners (left side green colored faces in above image) where the fins meet the frame. I am sure that they can be taken care of with some more effort. I would just likely bandaid this in the CAD file with a horizontal chamfer face in that sharp corner (about 0.3mm wide).
Like I said earlier you could reduce num cells further by setting ‘Cells between levels’ to a smaller number.
The leading and trailing edges of the fins are slightly jagged but likely OK for your purposes. In my geometry, the leading and trailing fin faces are 0.2549 mm wide which is only slightly larger than Level 7 distance of 0.2422 mm and which is likely the issue here.
In the long run, the abrupt and large cell volume ratio change between your single prism layer and the volume mesh cells should be investigated as to how much results accuracy is lost at this magnitude of volume ratio change.
1 layer meshing with absolute layering needs to be the subject of a sensitivity study. (unlikely to be as good of results as for wall function layering)
I think you should keep following this rabbit hole…
So i now have all the cell sizes measured out. The distance between where the fins meet is exactly 3mm so this is easy to work with. Calculating back we get a new level 0 cell size.
Level 0 (calculated) | 0.024m |
---|---|
Level 1 | 0.012m |
Level 2 | 0.006m |
Level 3 | 0.003m |
Level 4 | 0.0015m |
Level 5 | 0.00075m |
Level 6 | 0.000375m |
Level 7 | 0.0001875m |
At 6mm away from the first fin meeting point is where i will put the new (0,0) origin for the bounding box. With this i can be sure that the edges of the cells meet up with the geometry as shown on the right side of the CAD picture. I mapped out the cell size for each level also.
I worry that you are just concentrating on keeping the ‘left’ problem corners ‘onthegrid’. I think that for best results, it will turn out to be important to keep all 4 (5, since I forgot the right inside corner in that image) of those key points I showed earlier ‘onthegrid’.
Yes this could be causing my current problems of floating point exception. I copied your settings exactly an i keep getting in. I also tried my previous mesh settings and refinements and it still keeps coming back
RE: Floating point exception
I am pretty sure that ‘this’ led to a conclusion that you can not use a Feature refinement and a ‘Distance’ Region refinement both in the same mesh… See if you can confirm that… sometimes mesh refinements conflict with each other and can cause floating point exceptions…
Sorry, I have not broadcast that info yet
I think the distinction is that ‘Inside’ Region is OK but not ‘Distance’ region…
Let me review all this before I say more, this is just memory right now there are too many things in my head right now
I just tried the mesh again and deleted the region refinement altogether. I still have the error
I am still trying to figure out what my resolution was, but I guess my point is that floating point errors are caused for many reasons and can be as simple as conflicting mesh refinements, not just geometry/grid errors…
ah ok … super simple to mesh things huh?
I have decided to try to use cfMesh now in blueCFD, I will report if it is easier, ha…
EDIT: ‘In this case’ , neither I nor SimScale support could figure out why, when either a ‘Distance’ Region or an ‘Inside’ Region mesh refinement was added to a working set of refinements, a Floating Point Exception was encountered when meshing.
hmm i have tried a couple different runs with different refinements and still no luck.
I have another problem now on something that should be super easy. I want to see if my darcy-forchheimer coefficients are correct so that the porous media has the same pressure drop as the simulated radiator. So im doing the same radiator simulation but just with a porous media. I cannot get it to mesh, it keeps saying unexpected error. I have tried just 1 surface refinement, feature refinement and surface, surface and region, nothing works. I also tried the “Allow free standing faces” turned on and still nothing
Here is the project link. I have no idea why something so simple doesnt mesh
Then i wanted to do another porous media but sideways and it meshes first try
also should the porous zone be open like that? idk
Try the Chat bubble to support people that is on right side of screen when logged into your project.
After focusing more time on getting the porous media results to match the simulated radiator results, I have found some areas that are unclear. The first calculations of the Darcy Forchheimer coefficients have been recorded using alpha and beta values from the curve fit polynomial. The problem lies in the fact that removing the Y-Intercept changes the alpha and beta values in the equation. Doing so results in the following equation:
Where:
Alpha = 22.922
Beta = 4.39
This results in the following coefficients for the porous media
Darcy Coefficient without Y-intercept | 72895531.88 |
---|---|
Forchheimer Coefficient without Y-intercept | 403.59 |
I then ran two straight on porous media tests with the velocity and pressure drop data to relate to. This test was done with the following settings
Rad porous media test
Average Pressure drop assumed
Pressure before = 869 Pa
Pressure after = -2.5 Pa
Pressure drop = 871.5 Pa
Without y- intercept value - Pressure
Without Y- intercept value - Velocity
Velocity at face = 11 m/s
Results of Straight on Porous media without Y- Intercept VS actual data
Straight on Porous media without Y- Intercept | Actual Data | ||
---|---|---|---|
Velocity m/s | Pressure Drop Pa | Velocity m/s | Pressure Drop Pa |
11 m/s | 871.5 | 10.121 | 679 |
Difference | 0.879 | 192.5 |
With y- intercept value
The second radiator run was done using the same velocity settings as the first run (10.121 m/s). However this time the curve fit equation was slightly changed by adding the Y-Intercept selection. This gives the full equation, and with the Y- intercept ignored a new alpha and beta result. Which results in the equation.
This gives the following coefficients
Darcy Coefficient | 83272380.35 |
---|---|
Forchheimer Coefficient | 380.07 |
Pressure before = 879 Pa
Pressure after = -2.5 Pa
Pressure drop = 883.4 Pa
With Y- intercept value - Pressure
With Y- intercept value - Velocity
Velocity at face = 11m/s
Results of Straight on Porous media WITH Y- Intercept VS actual data
Straight on Porous media WITH Y- Intercept | Actual Data | ||
---|---|---|---|
Velocity m/s | Pressure Drop Pa | Velocity m/s | Pressure Drop Pa |
11 m/s | 883.4 | 10.121 | 679 |
Difference | 0.879 | 204.4 |
Rad verification sideways
Next I decided to simulate the radiator at the 50 degree angle it will be positioned at on the car. The results from these simulations provided better coherence to the actual data, which makes me think this was taken into account with the real radiator simulations. The first sideways radiator run was done using the same alpha and beta results WITH the Y-Intercept values kept and again using the same coefficients.
Darcy Coefficient | 83272380.35 |
---|---|
Forchheimer Coefficient | 380.07 |
Pressure before = 625 Pa
Pressure after = -12 Pa
Pressure drop = 637 Pa
50 deg angle - With Y- intercept value - Pressure
50 deg angle - With Y- intercept value - Velocity
Velocity at face ~ 10.8 m/s
Results of 50 deg angle Porous media WITH Y- Intercept VS actual data
50 deg angle Porous media WITH Y- Intercept | Actual Data | ||
---|---|---|---|
Velocity m/s | Pressure Drop Pa | Velocity m/s | Pressure Drop Pa |
10.8 m/s | 637 | 10.121 | 679 |
Difference | 0.679 | 42 |
Now there are some questions along with my setup of these tests.
In the 50 deg angle porous media i setup a housing so that the square porous media would not get cut off by the bounding box. The pressure and velocity cutting planes show disturbance in these areas and i’m not sure how it will affect the results
The data to be selected can vary a lot. The tilted radiator is, in my opinion, very close to my actual data, and if I simply collect my simulated data from different points i can make it match almost exactly. Sampling from this location gives me -35Pa after the radiator wich makes my new pressure drop 660 Pa. How accurate must this actually be? there are so many variables. I also have 10.121 m/s as inlet velocity not face velocity. This will further change the measurements.
This velocity profile is interesting. I’d say it’s likely related to these big surface cells that you have. y+ should be quite high here and the BL profile is not being captured appropriately. Remember that wall function bridges (models) the cell center to the surface.
The rest of the boundaries look normal because they’re set to slip walls.
Oh, i thought i didnt need a BL at all because its a porous media? I had everything set to slip walls (even the radiator housing) because i want the data from just the porous media. I wanted to do a BMB with only the media but that didnt mesh well. Also do you use the free standing zone faces?
With this off the radiator looks like this
With this option ON it looks like a normal volume
also speaking of velocity Profiles looking funny, on the 50 deg media test, i added a housing that tries to influence the flow as llittle as possible. The left arrow is an area of concern for me because this is an anisotropic media and the flow seems to be moving not so parallel with the medium. Is this my error or normal?
I have also tried a run with the whole setup, porous media, radiator exhaust into fans with MRF zones. The fans appear to be working but my particle traces dont seem to be going through the porous media. The settings are the exact same as the closed wind tunnel shown above. Any idea on whats going wrong?