code_saturne User's Forum

Hello,

In 2012, I developped a specific interaction model between particle on CS2.0 with the subroutine USLABO that gives me nice adequation with experimental data. I swtched to CS3 begining of 2013, and want to be back to this model, but I am not able to find the subroutine allowing to described the specific interaction as it was done with USLABO. In USLAG2 I can find how to deal with standard boundary interactions, but nothing about for instance the specific JBORD* type boundary condition.

Do I have to switch back to CS2.0 or CS2.3 or is there someone able to help me on how to have specific treamtment of particle / boundary insteraction in CS3.0 ? Thanks.

hello,

Additionnal question : is CS3.1 able to handle specific interaction between particle and boundary ? Does it make sense for me to switch forward to CS3.1 instead of backward with CS2.3 ? thanks.

Hello,

Well I tried to implement the subrtoutine uslabo in the cs_user_particle_tracking.f90, declaring the boundary as JBORD1. the thing is that it compiles, but as soon as it reaches an iteration where the particle hits this boundary, the code stopped with a error : "La condition limite 8 n'est pas reconnue." which I can translate in "boundary conditions 8 not recognize". Is this functionnality definitively removed from CS ?

Hi,

indeed, the file uslabo.f90 does not exist anymore in Code_Saturne v3.0 (even starting from v2.3 if I remember correctly.). The reason is two-fold: this routine was part of the 'trajectography', the set of routines dedicated to locate a particle in the domain. The trajectography was entirely rewritten in Code_Saturne v3.0 to accept parallel computation, and the language used is the C language.

The file of interest (encompassing all the trajectography) is cs_lagr_tracking.c ; the function dealing with particle-boundary interactions is _bdy_treatment. See for instance http://code-saturne.org/viewvc/saturne/ ... iew=markup , starting line 1979. In the process, this function was moved from user to kernel, essentially because 90% of uslabo was not intended to be modified by the user (and also, I did not know anyone who made use of the 'jbord' condition at that time)

I guess it would be possible to reinstore a user function to mimic to behavior of uslabo in future versions of Code_Saturne. In the meantime, I would suggest that you use the file cs_lagr_tracking.c and the function _bdy_treatment to program your own boundary condition where the IDEPFA condition (not implemented in v3.0) is supposed to be ; starting at
and to activate it in uslag2.

If it is not confidential, do not hesitate to post here your uslabo so that I may give you more precise advice

Hello Guingo, thanks for your answer.

"I guess it would be possible to reinstore a user function to mimic to behavior of uslabo in future versions of Code_Saturne." : YES please this was so helpful for me. This is also a part of the identity of Code_Saturne : to be a fully adjustable tool. Other CFD tools are not so customizable (morevoer they are not free), but CS is. Leaving the possibility to have several user subroutine for this boundary/particle interaction would be really helpful, at least for me...

"I would suggest that you use the file cs_lagr_tracking.c and the function _bdy_treatment to program your own boundary condition where the IDEPFA condition" . OK I will try that but do I need to compile after modification ? If not where do I put this modified file becasue if it does appear in the installer folder this does not appear in the configured folder ? Would it possible instead of using idepfa, to enable JBORD in the same routine, or is it more complex than that ?

"If it is not confidential, do not hesitate to post here your uslabo so that I may give you more precise advice" : it is not confidential, but this is nothing compared to the idpfa programation I have seen in CS3.1. This just act "black box" and reflect quite nicely the results we observed from experiments. I did not want to go deep into the fundamental behaviour of the particle/ boundary interaction, but just wanted to have a useable tool to understand what kind of improvement can be done on the device. I enclosed a part of the uslabo routine I used.

Really I want to thank you for this tool and the support, but please try to leave it as customizable as it was in version 2.0, if possible off course.

Hello,

You can simply add cs_lagr_tracking.c tou a case's SRC directory, and as long as you do not need to modify function signatures (ie. type and number of arguments) of non-local functions (i.e. those that do not begin with "static"), things should be fine.

Regards,

Yvan

Hello,

i think I will need some help. I would like globally to translate this that I wrote in my uslabo routine :

vi = abs(ettp(ip,jup) * surfbo(1,kface) &
+ ettp(ip,jvp) * surfbo(2,kface) &
+ ettp(ip,jwp) * surfbo(3,kface) ) &
/ surfbn(kface)

v=sqrt(ettp(ip,jup)**2+ettp(ip,jvp)**2+ettp(ip,jwp)**2)

energ = 0.5d0*ettp(ip,jmp)*(vi*vi) !
energt =6.d-14*v/vi

and I did this in the cs_lag_tracking :

cs_real_t face_norm[3] = {face_normal[0]/face_area,
face_normal[1]/face_area,
face_normal[2]/face_area};

vi= CS_ABS(_get_dot_prod(particle.velocity,face_norm))/face_area;

energ=0.5*particle.mass*vi*vi;
energt=6e-14*norm_vit/vi;

But this does not give exactly the same results when I run a claculation I already ran on CS2.0. I think I did a mistake certainly in the name of the different scalar. Could you help ? thanks.

Hi,

Maybe I am wrong, but I think you are dividing one time too many by face_area your variable vi in the CS 3.0 version of youir code. Perhaps the confusion stems from the fact that "surfbo({1,2,3}, kface)" in CS 2.0 is not a unit vector, but a vector whose norm is 'surfbn(kface)' . However, the C-equivalent you use, i.e. face_norm, is already a unit vector as you define it.

Best regards,

Mathieu

Ok thanks I missed that. Nothing else ? If I correct this both codes will be equivalent ? Because I wander if I correctly used "particle.mass". In fortran subroutine I directly used ettp(jmp) but with this in the C routine this does not work. I did not find anywhere the definition nor calculation of particle.mass, but I noticed that it was used somewhere in the code in the depo1 condition for instance. But I am not sure if this is the total mass of particles or the mass of the considered particle only that I set up in the gui.

Hi,

from what I read, once the correction done, the pieces of codes should be equivalent.

"particle.mass" is indeed the mass of one particle, so if you run a monodisperse calculation it should give basically the same value as any "ettp(ip,jmp)" (do not hesitate to perform some printf of the values if you have any doubt)

Best regards,
Mathieu