And yes you did point out correctly that boundary layers are needed for a more accurate simulation at the rotor and the side walls, but since the results are off by around 99.1%, setting boundary layers will not be enough.
Fundamentally, something is wrong with the setup. With reference back to your first copy of “Copy of 6.75-100%” where your outlet was set to gauge pressure 0, what was the Head value?
It was 10.8 [m] of Head, and that value is showed because I am considering a fixed pressure at the inlet which is not real in that run.
Backing to the real run, those are my experimental data, look:
Above you can see that I am having an inlet pressure of 201320 [kgm-1s-2] and an outlet pressure of 204158 [kgm-1s-2]. The main difference of the simulation and the experimental data is here, I guess. Please, let me know what you suggest me to do.
The circular faces of that zone are very confusing, that image shows it as basically a cup, not a cylinder.
Also do those longitudinal streaks on the surface of the zones cylinder cause a problem?
What am I missing?
I also see that SimScale imports the Fan component as a solid but when I import the geometry into Rhino, the fan is not a solid (perhaps due to small face edge deviations somewhere).
And the mesh has almost 100 illegal faces as shown in the meshing log…
This project has piqued my interest in that it appears that you have some significant experimental results that will allow us to determine how closely a CFD analysis can be made to match experimental results.
In that vein, I would like to investigate the accuracy of your CAD geometry and I have a few questions?
Was the CAD model ‘axial’, drawn from engineering drawings?
How many sections (ribs) were the blades lofted from? I am concerned since I do not think that the blades of this fan would have been built with this surface waviness:
Are there more details available for the fan that are not represented in your CAD, for instance, there is no ‘afterbody’ spinner on the downstream side of the fan.
Could you provide the details of the fan support structure that passes through the duct?
I will try to modify the current CAD file to work within the limitations of this CFD environment and try to get some close results.
Right now I think that the Snappy mesh algorithm is not meshing the MRF nicely due to the fact that it is only ~4mm larger than the fan blade diameter, first I will try to trim the fan blades a few mm smaller diameter and fix the fan edges that are not joined in Rhino.
What are your thoughts of MRF diameter (currently 1.4777 m) compared to duct diameter (currently 1.481 m diameter) and to the fan blade diameter (currently approximately 1.474 m diameter)?
Is the MRF sized properly with regard to its length and X coordinates of its circular end faces?
Would fan support structure that passes through the MRF affect the results accuracy (I assume they would not as all rotors need to be supported to some structure that passes through the MRF)?
I also assume that MRF’s CFD analysis somehow interact properly with, in this case the surrounding water flow and that any streamlines would not be discontinuous at the MRF boundaries, is that correct? (sorry this is my first experience with MRF’s)…
Great that you are interested in this. It should interesting to work on this together. Great questions to ask, lets see if we can deduce anything else from the geometry from @robnaz’s answers.
I initially saw that the blades are touching the MRF and I believe they are. From the mesh it seems like a cross-section of the blade profile can be seen at the MRF. This is workable but of course, not good. If however, the MRF diameter is larger than the fan blade diameter then it is ok. But it should also be smaller than the duct diameter. Based on what you measured, it should be ok. Though it would be best to give more margin between the MRF and the fan blade diameter as you have correctly pointed out, SnappyHexMesh tends not be happy with small margins like that (4mm).
I do think your geometry fix in Rhino would help the simulation plenty. I might do some modifications myself and re-run the mesh if needed.
The length of the MRF acts similarly to that of the diameter. As long as it is lengthwise longer than that of the length of the rotors then it is fine. With some margin of course.
Yes it would, unless the support is supposed to rotate with the fan or if the support is very thin/insignificant. Then again, you can have the supports inside the MRF. Just have to assign a moving wall velocity 0 in all directions to prevent the MRF from “rotating” the supports.
MRFs provide a rotational value to the geometry within its zone (hence the need for internal meshing). With no geometry, the MRF will not be able to apply a rotation and the flow will not rotate. So in essence, the MRF doesn’t interact with the flow but rather the geometry which then rotates the flow. No worries! I had ran into alot of problems with MRFs from another project. Quite an interesting parameter.
Ok, so we just make sure that the rear circular face of the MRF falls between (with space for Snappy) the rotor and the missing ‘afterbody’ and support members. For now, I would just ignore any CAD that is the shaft which the rotor is mounted on so that we have no structure passing through the MRF.
We can just ignore the support members and have the blades and center rotating cone encased within the MRF. Results can be fine tuned with a geometry update with the supports if needed. Otherwise, magic floating prop will do
Also, for the sake of completeness, could you confirm that your results chart was actually for a rotor speed of 21.476 radians/sec, inlet flow rate was 6.75 m^3/sec and the outlet pressure was 0Pa?
We only have a margin of 0.007 (diameter wise) to work with so maybe somewhere in the middle would be a good place to start. So 1.4775? Not much of a difference though, we might need to adjust the meshing settings to try and get snappyhexmesh to not screw around.
Please pay attention to coordinates of MFR zone. I experimented for a while with multiple MRF zones and discovered ‘half-rotating’ or even ‘rotating in both (+ / -) directions’ MRF zones. Setting probes points and observing velocity vectors convinced me about reality of those ‘impossible’ objects. For the moment, you can handle only one MRF zone and it should be centered on one of axes. Problem is reported and Ruben repeats that they are working on it.