code_saturne User's Forum

Dear friends,

I'm facing the problem of modeling a 3D photocatalytic reactor, hoping someone have the time for replying or make suggestions on the topic. I’m using Code Saturne 5.0.7 on a workstation running Ubuntu 16.04.

Basically the fluid flows into a channel where because of the coating on the wetted surfaces the transported pollutant molecules get oxidized according to a reaction rate which depends on both local pollutant concentration and local irradiance field (radiated from a source light within the fluid domain). The problem is implementing a model able to predict the lowering in pollutant concentration at the walls. Following some current literature the idea for solving the problem would be as follows:

1- solving for the irradiance field in the same geometry using an external tool and save it on given data files (the fluid is transparent to radiation)

2- mimic the oxidation process creating a (negative) volumetric source term for the transported variable (i.e. pollutant concentration) on the cell layers adjacent to the coated walls

3- to modeling the source via a reaction rate function which varies with both the local cell concentration and the imported irradiance values

Till now I was been able of implementing a simple steady laminar test case with one chemical active surface. The test is pretty rough especially because no heat release is considered nor new species formation and transport are modeled, but a simple non-linear source term is introduced at the bottom wall cells using cs_user_source_terms.f90 subroutine(if needed the complete case is attached below).

Now I’m facing the next step, i.e., adding the functional dependence from the irradiance field. What would be the right way for mapping the irradiation fields saved in external files onto the interested cells making such a new local parameter available to mathematically enter the source term expression? Note that meshes for the irradiance field aren’t the same of those in the fluid domain boundaries.

In the forum I' ve found something about data interpolation from external files (viewtopic.php?f=2&t=1872&hilit=import&start=10) but for standard code variables, hence any suggestion is welcomed.

Thank you all in advance, especially to EDF and for CS developers for letting the software open-source.


Alessandro

Hello,

What file format ae you using for the irradiance field ? Using the MEDCoupling library (with the Code_Saturne master branch, a.k.a. v5.3-alpha, mapping from a mesh in the MED format to the CFD mesh is quite easy and we can provide examples).

Otherwise, the PLE subsystem for Code_Saturne cans also be used to map from one mesh to another. Its documentation is a bit sparse, but once you have the data read, it is not to complex. The main question is how do you read the irradiance data ? Depending on the associated data format, this may be very or not so simple...

Best regards,

Yvan

Hello Yvan,
thanks for replying.

These are already good news, but unfortunately I cannot provide you any detailed information about the file formats now. The reason why is that I’ m still looking for an open-source tool able to performing the irradiance modelization (this is why I used the generic "given data files" expression in the post above).

In the reactor the light sources are LED arrays and according to what I currently see the best options would be using a ray tracing software (e.g. RADIANCE) or a simplified multipoint-LED source model (to be coded by myself using Gnu OCTAVE). Even if this is a little out-of-forum topic (maybe huge, in this case please ignore the request) any suggestion from you, if any, is appreciated.

Anyway, I’ ll come back here quickly with more details once I’ ll made the choice, but your reply has been essential because now I’ m sure that CS can do the job in some way and I can go on on this path.

Thanks a lot for your readiness, hoping to be here again in a very little.


Alessandro

Hello,

If you do not have a solver for irradiance yet, the radiative solver in Code_Saturne might be adaptable to your needs. It uses a Discrete Ordinates Method for resolution (probably not as precise as ray-tracing, but useful), and is based on thermal radiation, but might be easy to adapt. In which case you would not have any interpolation issues...

Another option might be adapting the thermal radiation (transparent) solver from the Syrthes tool, which is open source and uses (I believe) a ray-tracing approach, but I am not sure how we could adapt it so as to use only the radiative module and not the associated solid conduction part, so am not sure if this might be a good alternative or not...

Otherwise output from ray-tracing tools would probably be relatively easily adaptable, as most of these tools probably use triangle-based surface meshes, for which formats should be relatively simple...

Best regards,

Yvan

Hello Yvan,

thanks for your suggestions and sorry for the late in answering, but I’m still in the reasoning.

I’m start thinking that the best way for me would be attacking the problem with an increasing complexity. The idea probably will be:

1- to code a simplified tool for searching the ideal led pattern and reactor dimensions even if according to a very simplified optics (i.e. LED far-field approach without considering wall reflection, a practice that for this type of reactors it seems not so crazy to be considered). The main reason for this is that with a transparent fluid, optical optimization doesn't depend on the flow and a very quick tool will probably allow to avoid a huge 3D CFD campaign modelization. In doing this, probably first I will need to "attach" the optimized irradiance maps on the fluid boundaries in CS anyway.

2- Then, it would be great to modeling the previous optimized radiation problem in CS directly: instead of learning a ray tracing program I prefer with no doubt the idea of spending my time in working on CS, even if not sure about the time required and the problem complexity that I’ ll have to face to in modifying the existing radiative solver. But in this case what do you think about the led modeling? Intensity for this source is not spread equally in all directions and something is needed in the code to include also this effect for each LED of the array (composed of several dozen LEDs). Maybe this is a minor detail in the coding, especially because the vendor gives you intensity plots with varying the angle direction, but obviously is essential in modeling correctly the physics involved.

Thank you very much for the help and have a good week end.


Alessandro

Hello,

For 2), I guess each LED could be modeled as a local volume source term (in the current DOM solver, used for combustion, the black/grey body radiation sources are mostly heated gases in the volume, not boundaries, so that should be easy to adapt). DOM can use a number of directions depending on the chosen quadrature (one quadrature with 48 being often considered a good cost/precision balance; I don't remember whether it is S6 or DCT020-2468).

If you go through 1), you will probably have something better with ray-tracing than with DOM, so 2) might not be so useful, except possibly for computational cost aspects if the irradiation field varies in time and needs frequent updates, or as a simpler set-up (for which the ray-tracing results could serve as a basis for validation).

Also, using the radiative module in Code_Saturne, you can choose to solve every "n" fluid steps, so you an arrange to solve the irradiation field only once. The main question is how simple it would be to adapt the blackbody thermal radiation with zero absorption coefficient to your case. If you need only one bandwith (assuming the LEDS output in a narrow band, or in only a few bands), this is probably quite straightforward, though we would need to look into the details of the code.

Best regards,

Yvan

Hi Yvan,

thank you for the answers. I’ve no news now but yes, the irradiance field is steady and needs to be solved one time at all while LEDs would irradiate light in only one band. I’m agree with you about ray-tracing precision but likely it will be used a simpler program first rather than a ray-tracing software, at least for taking the fundamental decisions. This is why could be of help importing some kind of data files in CS anyway. Maybe use of a ray-tracing solution could be of some usefulness at a later stage (mainly once the simpler model has solved basic indecisions) and so the same for the radiative solver in CS... I’ll came back here as things become clearer because I'm still waiting some info on that.

Thank you very much again


Alessandro