Open DambronOlivier opened 5 years ago
Hi @DambronOlivier. Thank for sharing your thoughts. All good points and most of them are pretty straight forward to address.
I'm really glad @mostaphaRoudsari . Thanks so much!
There is also one more command that can be added after the snappyHexMesh that increases the speed of calculations.
snappyHexMesh renumberMesh -latestTime reconstructParMesh -latestTime
In case of multiple processors: mpirun -np X snappyHexMesh -parallel mpirun -np X renumberMesh -parallel -latestTime reconstructParMesh -latestTime
The wind tunnel grading component could output information about the resulting cellsize near each geometry with corresponding refinement level - cellsize after grading, cellsize near GeometryA after refinement level X, cellsize near GeometryB after refinement level Y.
Just a note on this, I think it would be good if other possibilities of cell sizing can be used as input. Using for example this link. Most often, we know cell sizes at different part of computational domain and boundaries not the percentage. For instance having representative lines with assign cellsize like the image below:
@SinaHassanli the component uses the same formulas as the link that you shared: https://github.com/ladybug-tools/butterfly/blob/master/butterfly/gradingutil.py so in theory it should be already possible. The new component needs to do some math in advance to convert between the two.
These are just a couple of ideas/notes for butterfly. If you share the view for any of these, I'd be really happy to help implement them however I can.
To help with meshing:
When geometries are assigned, run a check that there aren't any naked or non-manifold edges and preview them. For indoor cases, check that all the surfaces joined form a closed polysurface.
Create a component that serves the purpose of assigning the surface refinement levels. In the same way that the native gh Merge component allows to add/remove inputs, users would be able to set hierarchy to geometries. It could be good here to provide some tips about how to set this hierarchy (importance of refinement near details, openings, edges, flow of interest, pedestrian level; more relaxed for larger objects, walls, context, etc).
Features could be previewed per group of geometries, this would help users understand "b" of the refinement levels tuple "(a, b)".
The wind tunnel grading component could output information about the resulting cellsize near each geometry with corresponding refinement level - cellsize after grading, cellsize near GeometryA after refinement level X, cellsize near GeometryB after refinement level Y. One could imagine a "meshing legend" with a Square (cellsize), then split into 4 (ref lvl 1), splin into 8 (ref lvl2)... annotated with the geometries names and edge size.
Adding layers has not been crucial so far in my opinion, perhaps this adds complexity for new users and could be removed for now.
Additions wishes:
a. heat flux boundary condition to input w/m2 using: { type externalWallHeatFluxTemperature; mode flux; q uniform X [W/m^2] value $internalField; }
b. Adding the steady state solver buoyantSimpleFoam for indoor heattransfer. It considers radiation to calculate more accurate temperature distributions. This can be done by : - adding in /0 folder the G field and setting inputs for material emissivities for geometries:
/--------------------------------- C++ -----------------------------------\ | ========= | | | \ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \ / O peration | Version: v1706+ | | \ / A nd | Web: www.OpenFOAM.org | | \/ M anipulation | | *---------------------------------------------------------------------------/ / Butterfly 0.0.4 https://github.com/ladybug-tools/butterfly \ *---------------------------------------------------------------------------/ FoamFile { version 4.0; format ascii; class volScalarField; location "0"; object G; } dimensions [1 0 -3 0 0 0 0]; internalField uniform 0; boundaryField { concrete { type MarshakRadiation; emissivityMode lookup; emissivity uniform 0.90; value uniform 0; } outlet { type zeroGradient; } inlets { type zeroGradient; } }
- adding to /constant radiationProperties for the P1 model (the simplest to implement): /--------------------------------- C++ -----------------------------------\ | ========= | | | \ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \ / O peration | Version: 5 | | \ / A nd | Web: www.OpenFOAM.org | | \/ M anipulation | | *---------------------------------------------------------------------------/ FoamFile { version 2.0; format ascii; class dictionary; location "constant"; object radiationProperties; } // //
radiation on;
radiationModel P1;
// Number of flow iterations per radiation iteration solverFreq 1;
absorptionEmissionModel constantAbsorptionEmission;
constantAbsorptionEmissionCoeffs { absorptivity absorptivity [0 -1 0 0 0 0 0] 0.5; emissivity emissivity [0 -1 0 0 0 0 0] 0.5; E E [1 -1 -3 0 0 0 0] 0; }
scatterModel none;
sootModel none;
// ***** //
- modifying the fvSolution by adding G as follows: /--------------------------------- C++ -----------------------------------\ ========= | \ / F ield | OpenFOAM: The Open Source CFD Toolbox \ / O peration | Website: https://openfoam.org \ / A nd | Version: 6 \/ M anipulation | *---------------------------------------------------------------------------/ FoamFile { version 2.0; format ascii; class dictionary; location "system"; object fvSolution; } // //
solvers { p_rgh { solver PCG; preconditioner DIC; tolerance 1e-06; relTol 0.01; }
}
SIMPLE { nNonOrthogonalCorrectors 0; pRefCell 0; pRefValue 0;
}
relaxationFactors { fields { rho 1.0; p_rgh 0.7; } equations { U 0.2; h 0.2; "(k|epsilon|R)" 0.5; G 0.7; } }
// ***** //