I want to add Solar Radiation
 

I want to add Solar Radiation modelling functionality to OF. It would be extremely important for engineering problems. I am thinking of coupling either with the SOLPOS algorithm:
http://rredc.nrel.gov/solar/codes_algs/solpos/
or the SPA (http://rredc.nrel.gov/solar/codesandalgorithms/spa/)

Both calculate the sun's intensity and position in the sky for a given day.
Any ideas of effcient ways of doing that would be
welcomed.

St

>Both calculate the sun's inte
 

>Both calculate the sun's intensity and position in the sky for a given day.
>Any ideas of effcient ways of doing that would be welcomed.

Probably the codes in your link already are efficient. If not, there are hundreds of other programs for celestial mechanics. No point in doing the calculations in openfoam.

Bertram

there are many engineering pro
 

there are many engineering problems where Solar radiation has very important role. Such problems include CFD modelling for sustainable building design, a fast growing market. Cases include stack ventilation in building facades, atriums, effects of shading devices etc. Currently I think that only FLUENT has a convinient way to model that. It wouldn't be difficult to add the Sun as a rediative heat source, provided that we know its position.

As a first shot I suggest you
 

As a first shot I suggest you check out how Fluent does it and then try to do something similar in terms of implementation. If will be much easier to give you advice on specific implementation elements than the overall solution strategy .

I agree that this would be a n
 

I agree that this would be a nice feature.

Several years ago, several people in our group did a green building analysis, and used an in-house CFD code, and RADTHERM for generating the solar loads.

Conference paper

story on treehugger.com

story in edcmag.com

It would be cool to do this with OpenFOAM and a non-commercial solar-radiation package. However, I should point out that RADTHERM had alot of capability, such as: effects of solar radiation as a function of the position of sun and atmospheric conditions provided by an external weather file, full shadowing based on time of day, geometry, reflections, re-radiation between geometric features, glass regions that are transparent to solar radiation but opaque to infrared radiation, and sky radiation. We used the solar loads generated by RADTHERM as the forcing functions in our CFD simulations which we ran for several days of simulated time, and at different conditions over the year (winter, summer, spring, fall).

Fun Stuff,


Eric

Eric: Thanks for the papers. S
 

Eric: Thanks for the papers. SOLPOS is able to calculate all the sky radiation factors that you mentioned and teh cloud-cover factor can be introduced by an external database. It is incorporated in teh r.sun model of the opensource GIS model GRASS and radiation fluxes on raster surfaces using SOLPOS.

Eugene: A quick search gave me that FLUENT introduced teh solar radiation back in the 2002 and seems that they used a simmilar method to SOLPOS: Airpak 2.1 provides a solar shading model, which accounts for the local date, time, and geographic position to compute the solar intensity and angle. This direct solar radiation information is combined with the user-specified characterization of the solar radiation entering the building. So I guess it is a matter of creating a radiative heat boundary condition (SUN) and its position and intensity will be calculated by SOLPOS (opensource) for a given day/time.

From the information you have
 

From the information you have provided, the main missing piece (aside from the Solar "inlet" boundary) seems to be the radiation solver. The currently available P1 model is, to my knowledge, not really ideal for non-participating media like air.

I know some work has been done on more complicated radiation models in OpenFOAM, but I have no idea in what the current state is or if/when it will be completed. Alternatively, you will have to do some work coupling an external radiation solver with the OpenFOAM thermal boundaries.

Thanks Eugene, Alternative
 

Thanks Eugene,

Alternatively, SOLPOS could be used to calculate the heatfluxes from solar radiation on all extyernal surfaces, based on the cell's angle against the SUN. Am i right?

Not sure this would work very
 

Not sure this would work very well. The sun would only shine through the windows. Non-transmissive outside boundaries (like brick walls and the roof) would block the radiation. As a result of the shadowing effect, solar incidence on internal walls would be non-trivial to calculate, certainly just considering the orientation of the outside surface would be a gross over-simplification.

The ideal model to do this kind of thing would be something like discrete ordinance or view factor.
However, if you are only interested in finding out which surface elements receive solar radiation, you could use a directional flux transport equation to track the sunshine from the window to wherever it impacts. This approach would not allow for general surface-to-surface radiation modeling though.

All, In building simulation
 

All,

In building simulation world, this issue has been discussed for quite some time. Some of the issues raised in this thread has also been discussed.

For more information: go to www.ibpsa.org and there is a full-text link to the proceedings of the bi-annual Building Simulation conference. You should also google "building simulation cfd coupling".

In a nutshell, here are some of the important points:

1. CFD is "just" one of the tools that building designers can use. When and how it should be used, that remains the question for every project.

2. The most important tool for building design, that is used for code compliance and green building certification, is the energy simulation. This simulation runs on annual basis with at least hourly time step. To be effectively used in building design, CFD should be used not in isolation with this energy simulation.

3. The typical use of CFD in building design is to test worst case scenario(s), which means the condition only happens on a certain time of the day and a certain time of the year. It is not feasible (and not necessary) to run CFD simulation for every hour of the year. In other words, conjugate heat transfer method is not really the future for CFD in building design (but I might be wrong or might change my opinion in the near future)

4. The more advanced use of CFD is to have a coupled simulation between building energy simulation (BES) and CFD. BES can supply the boundary conditions for the CFD, which includes the wall temperatures, inlet and outlet temperatures of the air conditioning system. In turn, BES will receive an updated convection coefficient from CFD for its calculation of convection heat transfer in the walls. The coupled CFD simulation usually happen on the time steps that are pre-determined by the building designer, and they are all steady state CFD simulations.

5. So far, the use of CFD in the CFD-coupled BES is limited to the convection part of it. But it is not difficult to imagine the addition of the radiation part. The BES has all the information for solar radiation: the sun position, the amount of solar energy that goes into the zone, and the exact location where direct solar radiation falls. A coupled-CFD simulation can have all this information from BES.

6. ESP-r and EnergyPlus, the two leading BES software, have done their own research on CFD coupling. For ESP-r, the CFD module is even included in the source code package. I spent a few years to make ESP-r "talks" to an external CFD package (Fluent is the software that I used). I just know OpenFoam, and I am working to replicate what I have done with Fluent.

(but I am still stuck because the tutorial case for buoyantSimpleFoam does not work for me. well, I will just keep trying)

Thats all for now folks. I hope this information helps in avoiding "re-inventing the wheels".

I don't mind reinventing the w
 

I don't mind reinventing the wheel as long as it gives me a free wheel

However your ideas are very us
 

However your ideas are very usefull Ery! Thank you for your detailed post. I have been using various thermal softwares in the past and indeed interfacing them to CFD would be very benefitial not only in terms of "not reinventing the wheel" but also brings consistency between different tools used in a project. I would more than wellcome your help of how the OpenFoam community could use OF along with a thermal simulation tool such as esp-r or energyplus. ePLUS would be preferable as it can already interface to sketchup, then it means that OF users would be able to design in Skethcup, a free tool, then mesh and calculate BCs in ePLUS and use OF as a CFD solver.

Best regards,
S P

Follow up after a year!
 

It has been almost a year since the last post to this thread, so not sure if I'll get a reply. Did any of you actually work on the solar model for OpenFoam? I am only starting to look into OpenFoam for building simulations and would immensely benefit from any advice you might have to offer.

One of the options that I was thinking of is, possibly develop the model (or geometry) in Airpak, save it out, use the Fluent-to-Openfoam geometry converter to get the case in Openfoam. How hard it is to do such a thing? And again, is the radiation model available in Openfoam good (in terms of usability, accuracy, detail, etc.) for such simulations.

Thanks!
ADS

I actually wrote the original solar load module for FLUENT as a UDF many years ago. It uses SOLPOS to compute the location and intensity of the sun. To make it efficient, I dotted the normal of each boundary face with the sun direction, did some backface culling, and then sorted the remaining faces into a quad-tree based on a coordinate system defined with the sun in the z-direction. Then doing the shading calculation is very efficient because all of the potentially shading faces where in the same branch of the quad-tree. Others have worked on the solar load component since, so maybe it is doing something different now.

If I were writing it now, I would not do it this way though. There is no nice way to build the quad-tree in parallel because the parallel partitioning is completely independent of the sun direction...so the choice is either to repartition using the solar direction as a "do not partition" axis or to do a lot of communication merging the per-process quad-trees. If I did it now, I would solve the radiative transport equation along a single direction (the sun direction) using the normal FV treatment. This would also open the door for full reflection/scattering if more directions were included al a DO. In either case, the parallel treatment is transparently handled as the RTE(s) are just fixed flux transport equations.

Energy Equation
 

Hi there,

I have copied my energy equation (hEqn) below. Any idea why I get very large values for h (and ultimately for T) at the very beginning of the iteration? The solver stops after 3 or 4 iterations.

Thanks alot,

{
volTensorField gradU = fvc::grad(U);

//stress tensor
volTensorField tau =
- nu * (gradU + gradU.T())
+
(2.0/3.0 * nu * fvc::div(U)) * I;

volScalarField tauGradU = tau && gradU;

solve
(

fvm::div(phi, h)
- fvm::laplacian(kl/Cp, h)
==

fvc::div(p*U)
- p * fvc::div(U)
- tauGradU
);

// correct temperature
T = T0 + h / Cp;

}

Hi Erydj

I read your PhD thesis just now, may I ask you more details in coupling method?

Thanks