Specific particle / boundary interaction : USLABO

[frpageot]

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.

[frpageot]

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.

[frpageot]

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 ?

[guingo]

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

Code: Select all

  else if (bdy_conditions->b_zone_natures[boundary_zone] == CS_LAGR_IDEPFA)

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

[frpageot]

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.

[Yvan Fournier]

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

[frpageot]

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.

[guingo]

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

[frpageot]

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.

[guingo]

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