call temperature when solving enthalpy thermal scalar

[rodion]

Thank you Cyril for you answer.

As far as I can see, dp_ELE is for plasma forming gas. But I need to involve electrodes (tungsten and copper) inside of the domain and I have files with properties of these metals. So could you please explain:
1. How can I impose properties (temperature, specific heat, thermal and electrical conductivity) of the metals inside of electrodes?

2. How can I impose the special electrical conductivity near the electrode surface (electrode sheath)?
I've tried to get access to electrical conductivity in uselph(cs_user_physical_properties.f90) using following subroutines:
call field_get_key_int (ivarfl(isca(ipotr)), kivisl, ifcsig)
call field_get_val_s(ifcsig, cpro_sig)
But I've got this error in compile.log:
...\src_saturne\cs_user_physical_properties.f90:337.43:
call field_get_key_int (ivarfl(isca(ipotr)), kivisl, ifcsig)
1
Error: Symbol 'ipotr' at (1) has no IMPLICIT type

3. I need temperature field. What is the essential difference between following two ways of creating the property field "temperature"?
__a. call add_property_field('temperature', 'Temperature', itemp)
__b. call field_create('temperature', itycat, ityloc, idim1, ilved, inoprv, f_id)

Best regards,
Rodion

[Yvan Fournier]

Hello,

Here are some answers:

1) the electrode is outside the fluid domain, so its properties are not handled inside Code_Saturne.
You could add a model in user subroutines, but you need to code it yourself... Another solution might be to use conjugate heat transfer with Syrthes, if you can establish a relation between thermal and electrical conductivity, but I have not given it detailed thought...

2) the ipotr integer probably dissapeared when moving to C. You could access the properties from C using field pointer macros (probably CS_F(ipotr)) but a solution working in both C and Fortran is to access the field by name. I'm not in front of my computer right now so instead of giving you a possibly wrong answer, I'll let you check the Doxygen documentation user exemples for the exact syntax. Also, you can use the setup.log from previous runs to check the exact name of the electric potential field.

3) defining a field as a property adds a few default settings (for logging en postprocessing at least) compared to simply defining a field, so it is generally recommended to use this higher-level definition.

Regards,

Yvan

[rodion]

Thank you for your answer, Yvan.

1. My goal is to avoid direct establishing of boundary conditions at the electrode surface. So I have to involve electrodes into the simulation domain and impose its properties for the simulation.
I have files with properties of tungsten and copper (T->H, Cp).
I've tried to do it, using cs_user_physical_properties.f90 and usthht.f90, but unfortunately, I can see only properties from dp_ELE in the postprocessing files.
How can I impose properties (temperature, specific heat, thermal and electrical conductivity) of the metals inside of electrodes using this files?

3. Does the following line add temperature field in the postprocessing files for visualisation by default? And where should I add this line?
call add_property_field('temperature', 'Temperature', itemp)

[daniele]

Dear Yvan,

I have the field "temperature" created and activated, but my problem is that I don't know how to fill it with the temperature values calculated by the usthht.f90.

I guess I have to call the usthht routine somewhere, do something like a for cycle around all the iel cells passing the usthht value to the "temperature" array...
I tried to that inside the cs_user_parameters.f90, in the same place where I create the field "temperature", but that doesn't work, I have a compiling error. Is the usthht executed after the cs_user_parameters?

Thanks a lot in advance.

Best regards,

Daniele

[Yvan Fournier]

Hello,

cs_user_parameters.f90 is executed before the time loop do it is not the routine you need.

I suggest cs_user_extra_operations.

Best regards,

Yvan

[daniele]

Dear Yvan,
I see the procedure, but still I have a few blocking points.

I created the new user field inside the cs_user_parameters.f90 through:

call field_create('temper', itycat, ityloc, idim1, inoprv, f_id)

Now in the cs_user_extra_operations.f90 I can call for the enthalpy to temperature conversion:

call usthht(1,enth(iel),temp)

But once I have the value of “temp” provided bu the usthht, I need a function able to transfer temp(iel) into ‘temper’(iel), which I do not know.
Moreover, in order to use the new field called “temper” I guess I have to know its field name (something like ivarfl(itemper)), which I do not know neither.
These are the two issues that I cannot solve in order to have the temperature values filled inside the new field.

Thanks a lot for your help.
Best regards,
Daniele

[Yvan Fournier]

Hello,

Instead of a single "temp" value, you need to define a pointer to the property where local variables are defined. Using recommended namings (cpro_temp instead of temp to be compatible with most examples):

Code: Select all

double precision, dimension(:), pointer :: cpro_temp

Then in the code, before the call to usthtt:

Code: Select all

call field_get_val_s_by_name('temper', cpro_temp)
call usthht(1, enth(iel), cpro_temp(iel))

Regards,

Yvan

[daniele]

Hello Yvan,

Thanks a lot for your help, it finally works fine now!

I had to use “isca(1)” instead of “ivarh” to call the enthalpy, because using “ivarh” I had a problem of “Fortran pointer of rank 1 requested for values of field "velocity",
which have rank 2 ».
Do you know why ?


call field_get_val_s_by_name('temper', cpro_temp)

call field_get_val_s(ivarfl(isca(1)), enth)

do iel = 1, ncel
call usthht(1,enth(iel),cpro_temp(iel))
enddo


Many thanks.
Best regards,
Daniele

[Yvan Fournier]

Hello,

ivarh is probably defined only when using some specific models. Since you are using enthalpy with your own model (and not one of the prefined "specific physical models"), many of the things which are usually predefined need to be defined here.

I would recommend using isca(iscalt) instead of isca(1), so that if you add "user" scalars (such as tracers) in the future, your code will still work.

Best regards,

Yvan