[Lann]

Hey foamers,

I am currently adding some new fields and equations to chtMultiRegionFoam.
There's a quite good reference report:
http://www.tfd.chalmers.se/~hani/kur...roject0126.pdf
in which they used solidWallMixedTemperatureCoupled for boundary condition of the new field added. What they did in this BC was like replacing T with the new field Vel:

type solidWallMixedTemperatureCoupled;
neighbourFieldName Vel;
K sigma;
value uniform 0;

However, this just works for elder versions of openfoam. I'm using openfoam 6, where this BC is no longer available.

In openfoam 6, the BC used for temperature in the tutorials is:

type compressible::turbulentTemperatureCoupledBaffleMix ed;
Tnbr T;
kappaMethod fluidThermo;
kappaName none;
value uniform 300;

What I did was simply replacing T with the field I created:

type compressible::turbulentTemperatureCoupledBaffleMix ed;
Tnbr fH;
kappaMethod fluidThermo;
kappaName sigma_H;
value uniform 0;

This does not work when I run my solver. Here's the error:

PIMPLE: Operating solver in PISO mode

Region: anode Diffusion Number mean: 3.555556e+08 max: 1.422222e+09
Region: membrane Diffusion Number mean: 8.888889e+08 max: 3.555556e+09
Region: cathode Diffusion Number mean: 3.555556e+08 max: 1.422222e+09
Region: anode Diffusion Number mean: 3.555556e+08 max: 1.422222e+09
Region: membrane Diffusion Number mean: 8.888889e+08 max: 3.555556e+09
Region: cathode Diffusion Number mean: 3.555556e+08 max: 1.422222e+09
Time = 1


Solving for solid region anode
DICPCG: Solving for h, Initial residual = 0.2731207, Final residual = 1.206402e-15, No Iterations 1


--> FOAM FATAL ERROR:
kappaMethod defined to employ fluidThermo method, but thermo package not available

From function Foam::tmp<Foam::Field<double> > Foam::temperatureCoupledBase::kappa(const scalarField&) const
in file turbulentFluidThermoModels/derivedFvPatchFields/temperatureCoupledBase/temperatureCoupledBase.C at line 171.

FOAM exiting

Btw here's a guide of this BC, but I cannot find anything useful.
https://www.openfoam.com/documentati...99f556a07d5c9f

Any help will be deeply appreciated.

Thanks in advance.

Lan

[Lann]

Stuck in here for days, still no clue.
Can someone give some tips? Many thanks!

[crubio.abujas]

Hello Lann,

I've been checking the source code to find what could be going on. The code I've found basically it search for the method to use for calculating the thermal conductivity. If you've chosen fluid it tries find for a turbulence model and use the turbulent effective conductivity, or otherwise look for a fluidThermo object inside the register. In case none of those options are available it raises the "thermo package not available". The file where the error is raised is "temperatureCoupledBase.C", if you want to check it.

I've tried to replicate the error myself setting a wrong thermo, but OF will catch it and expose the available solutions. The only way I've managed to raise the "thermo package not available" is swapping the kappaMethod on the regions (this is, setting a fluidThermo to a solid region).

You may want to check the constant/region/thermoPhysicalProperties and ensure that all the thermoTypes match what is defined in 0/region/T. If the region is a solid it must have a heRhoThermo, but none of the fluid regions shall have this type.

Let's hope that can solve your problem!

[Lann]

Originally Posted by crubio.abujas

Hello Lann,

I've been checking the source code to find what could be going on. The code I've found basically it search for the method to use for calculating the thermal conductivity. If you've chosen fluid it tries find for a turbulence model and use the turbulent effective conductivity, or otherwise look for a fluidThermo object inside the register. In case none of those options are available it raises the "thermo package not available". The file where the error is raised is "temperatureCoupledBase.C", if you want to check it.

I've tried to replicate the error myself setting a wrong thermo, but OF will catch it and expose the available solutions. The only way I've managed to raise the "thermo package not available" is swapping the kappaMethod on the regions (this is, setting a fluidThermo to a solid region).

You may want to check the constant/region/thermoPhysicalProperties and ensure that all the thermoTypes match what is defined in 0/region/T. If the region is a solid it must have a heRhoThermo, but none of the fluid regions shall have this type.

Let's hope that can solve your problem!

Hey Carlos,

Thank you so much for your reply. One thing I found that may cause the error is that the diffusivity I defined is a volScalorField. I did that because it's easier to add to the solver file, even though it's constant. All I need is a BC that fits my situation, that is on both sides of the interface the electric potential (I added in the solver) is equal.

So I am not sure if it's a good idea to use solidWallMixedTemperatureCoupled. I used it only because it is used for temperature on the interface. I don't know for the electric potential fH (which I added to the solver) is there any other BCs more suitable?

Thanks,

Lan

[crubio.abujas]

Ok, I missed the point. If you're not working with a temperature there it has sense that it blows trying to find a thermo object. What you want is just to ensure that fH in the patch regA_to_regB is equal to the one in regB_to_regA, right? In that case you can try a mapped patch.

regA_to_regB
{
    type                mapped;
    setAverage          false;
    average             0;
    value               0;
}

It will set the field of this patch equal to the one of the other patch. The information of the sampleRegion and samplePatch shall be present in the polyMesh folder (boundary file), so no need to supply it here.

You still have to solve how the regB_to_regA is connected to your problem, otherwise they will get stuck to the initial value of 0 and you will not model the connection among regions. Maybe setting to zeroGradient, or a fixed volume or whatever your problem needs.

I think that generally you need to set some kind of balance in the interphase. The phenomena that is occurring in one side has to be connected somehow with the ones happening on the other side. In the case of temperature you have to ensure a energy balance between the heat transmitted along the two sides.

Let's hope that helps you to advance with your model.
Carlos

[Lann]

Originally Posted by crubio.abujas

Ok, I missed the point. If you're not working with a temperature there it has sense that it blows trying to find a thermo object. What you want is just to ensure that fH in the patch regA_to_regB is equal to the one in regB_to_regA, right? In that case you can try a mapped patch.

regA_to_regB
{
    type                mapped;
    setAverage          false;
    average             0;
    value               0;
}

It will set the field of this patch equal to the one of the other patch. The information of the sampleRegion and samplePatch shall be present in the polyMesh folder (boundary file), so no need to supply it here.

You still have to solve how the regB_to_regA is connected to your problem, otherwise they will get stuck to the initial value of 0 and you will not model the connection among regions. Maybe setting to zeroGradient, or a fixed volume or whatever your problem needs.

I think that generally you need to set some kind of balance in the interphase. The phenomena that is occurring in one side has to be connected somehow with the ones happening on the other side. In the case of temperature you have to ensure a energy balance between the heat transmitted along the two sides.

Let's hope that helps you to advance with your model.
Carlos

Hi Carlos,

Could you please explain where to solve how the regB_to_regA is connected? (Where should I add some codes?)

I left the BC like you did:

{
type mapped;
setAverage false;
average 0;
value 0;
}

From the result, I see exactly what you said: hey got stuck to the initial value of 0, and did not solve the equation.

There's also this warning in the log file:

--> FOAM Warning :
From function Foam::Field<Type>::Field(const Foam::word&, const Foam::dictionary&, Foam::label) [with Type = double; Foam::label = int]
in file /opt/openfoam6/src/OpenFOAM/lnInclude/Field.C at line 324
Reading "/home/lan/OpenFOAM/lan-6/run/mem+electrodes/0/anode/fH.boundaryField.anode_to_membrane" from line 45 to line 48
expected keyword 'uniform' or 'nonuniform', assuming deprecated Field format from Foam version 2.0.

I understand there's another connection between two sides, which, for my case of the electric field, may be the electric current flow. However, I don't know where to add this connection.

Thanks for your patience.

Best,
Lan

[crubio.abujas]

Hello again Lann,

Originally Posted by Lann

Could you please explain where to solve how the regB_to_regA is connected? (Where should I add some codes?)

From the error message I can infer that you have in the 0 folder two regions(folders) one is anode and the other it membrane.

In one of them, let's say anode, you set the mapped patch on the anode_to_membrane. What this will do is to copy the values of the patch membrane_to_anode(from the region membrane) into anode_to_membrane(from the region anode). Thus, a link is created among these two regions: anode will be bounded to the region membrane (but not the opposite).

Be aware that, in this scenario, the region membrane is not aware of the existence of the region anode as there is no link in the direction anode->membrane, just membrane->anode. Thus you must still set a meaningful boundary to membrane_to_anode, for example zeroGradient. OF will solve membrane region using this boundary condition and, afterwards, impose the values obtained in the surface into anode_to_membrane for solving the region anode.

This may be a too simplistic model for many situations, but at least may give you some insight on how to connect regions. For a more complex interaction between these two regions you must define how these two fields are coupled, as is the example of the temperature coupled. In this case the different region temperatures, effective conductivities and maybe surface radiations are used to calculate the surface temperature that adjust a thermal balance, and then each region is solved separately.

For doing this you may need to write your own BC. You can use compressible::turbulentTemperatureCoupledBaffleMix ed as a template, for this.

P.D: The warning is just telling you that the mapped shall be described as:

regA_to_regB 
{
type mapped;
average 0;
value  uniform 0;
}

[Lann]

Originally Posted by crubio.abujas

Hello again Lann,


From the error message I can infer that you have in the 0 folder two regions(folders) one is anode and the other it membrane.

In one of them, let's say anode, you set the mapped patch on the anode_to_membrane. What this will do is to copy the values of the patch membrane_to_anode(from the region membrane) into anode_to_membrane(from the region anode). Thus, a link is created among these two regions: anode will be bounded to the region membrane (but not the opposite).

Be aware that, in this scenario, the region membrane is not aware of the existence of the region anode as there is no link in the direction anode->membrane, just membrane->anode. Thus you must still set a meaningful boundary to membrane_to_anode, for example zeroGradient. OF will solve membrane region using this boundary condition and, afterwards, impose the values obtained in the surface into anode_to_membrane for solving the region anode.

This may be a too simplistic model for many situations, but at least may give you some insight on how to connect regions. For a more complex interaction between these two regions you must define how these two fields are coupled, as is the example of the temperature coupled. In this case the different region temperatures, effective conductivities and maybe surface radiations are used to calculate the surface temperature that adjust a thermal balance, and then each region is solved separately.

For doing this you may need to write your own BC. You can use compressible::turbulentTemperatureCoupledBaffleMix ed as a template, for this.

P.D: The warning is just telling you that the mapped shall be described as:

regA_to_regB 
{
type mapped;
average 0;
value  uniform 0;
}

Hi Carlos!

Sorry to write to you after 3 months. Unfortunately, I'm still stuck in the problem I mentioned above.

Basically, I need to find, or build, a BC on the interface of two regions (anode and membrane) that enures the scalar (electric potential) on each side is equal and the current (sigma*grad.fi) is equal, just like two joint walls having same temperature and heat flux on the interface.

As you suggested before, I tried to build a new BC based on compressible::turbulentTemperatureCoupledBaffleMix. However, I cannot change the diffusivity (kappa) inside this BC, because kappa is strongly linked to the thermal model and cannot be replaced.

Luckily, I found a similar BC that can be used directly for my case, that is

solidWallMixedTemperatureCoupledFvPatchScalarField

It can be used directly because the kappa and T can be replaced by any diffusivity and scalar filed in the case file, that compressible::turbulentTemperatureCoupledBaffleMix cannot do.

However, solidWallMixedTemperatureCoupledFvPatchScalarField only exit in old versions of OF and was removed then.

Now for newer version of OF, compressible::turbulentTemperatureCoupledBaffleMix was implemented for replacing solidWallMixedTemperatureCoupledFvPatchScalarField and can adjust to a wider range of situations, like two-phase interface.... However, it can be only used for temperature and kappa.

Then I tried to add compressible::turbulentTemperatureCoupledBaffleMix to my OF6, but I failed due to there's several files included that is modified or missing in my OF6.

I am wonder if I should continue building a new BC, or try to implement compressible::turbulentTemperatureCoupledBaffleMix (old version BC) to my OF6 until it works implement, or maybe there's just better BC that works for my case.

I know what I wrote is too long and you were helping me without return, so it's ok if you cannot help more.

Thank you for having helped a lot.

Lan

[crubio.abujas]

Hello Lann,

Sorry for being missing so long. I've seen your post but I cannot find any time to think about it and give you an answer untill now.

I've been seeing the code on turbulentTemperatureCoupledBaffleMixed and I've seen the relation with kappa that you mention, but I think it would not be so hard to overcome this issue by overwritting the kappa function (defined on temperatureCoupledBase).

I'm going to try to write a potentialCoupledBaddleMixed code so you can use it in your model. In mi mind I think that the sigma funcion is not dependent on the electrical potential, right? It may be dependent on the temperature, but let's first try it with a constant sigma, ok?

I let you know when I have the time to modify and try the code, but it will be quite usefull if you can share with me some test-case and solver so I can make some trials by my own.

[Lann]

Originally Posted by crubio.abujas

Hello Lann,

Sorry for being missing so long. I've seen your post but I cannot find any time to think about it and give you an answer untill now.

I've been seeing the code on turbulentTemperatureCoupledBaffleMixed and I've seen the relation with kappa that you mention, but I think it would not be so hard to overcome this issue by overwritting the kappa function (defined on temperatureCoupledBase).

I'm going to try to write a potentialCoupledBaddleMixed code so you can use it in your model. In mi mind I think that the sigma funcion is not dependent on the electrical potential, right? It may be dependent on the temperature, but let's first try it with a constant sigma, ok?

I let you know when I have the time to modify and try the code, but it will be quite usefull if you can share with me some test-case and solver so I can make some trials by my own.

Hi Carlos,

Thank you for your reply! Yes, the sigma funcion is not dependent on the electrical potential nor on the temperature at the moment (may study the temperature dependent issue in the future). Just wanna let you know the sigma is defined as a volume scalar in the solver.

I'll send you the solver and test case right away. Thanks again!

Lan

[crubio.abujas]

Originally Posted by Lann

Hi Carlos,

Thank you for your reply! Yes, the sigma funcion is not dependent on the electrical potential nor on the temperature at the moment (may study the temperature dependent issue in the future). Just wanna let you know the sigma is defined as a volume scalar in the solver.

I'll send you the solver and test case right away. Thanks again!

Lan

Hi again Lann,

I've been working on this condition and I think I already have something you can try. I didn't have the chance to look your solver in detail. I see that you have a couple sigma fields on each domain (sigma_e and sigma_H). I am not familiar with the resolution of electromagnetic equations so I do not fully comprehed these terms. I'm guessing that they are electrical conductivities, but why there are two of them? Anyway if you define as scalarFields is because they have different values along the domain, isn't it?

As I cannot identify properly the usage of these fields, I just defined the boundary condition so you can define the value of sigma of the interface in the boundary itself (see the example bellow)

regA_to_regB
{
     type    potentialCoupledBaffleMixed;
     Tnbr   T;    // or the name of the potential field
     sigma 1000;   // The value of sigma in the regA
}

This sets the boundary condition to a fixed value in the interface. You have to define the boundary regB_to_regA as a potentialCoupledBaffleMixed, as well (and define a different value of sigma if you want).
For this to work you have to compile the code I attached bellow (I've tried on OF7, but it shall compile on OF6 as well) and add the resultant library on the controlDict:

libs            ("libpotentialcoupled.so");

Let me know any further problem you may have with this code!

[Lann]

Originally Posted by crubio.abujas

Hi again Lann,

I've been working on this condition and I think I already have something you can try. I didn't have the chance to look your solver in detail. I see that you have a couple sigma fields on each domain (sigma_e and sigma_H). I am not familiar with the resolution of electromagnetic equations so I do not fully comprehed these terms. I'm guessing that they are electrical conductivities, but why there are two of them? Anyway if you define as scalarFields is because they have different values along the domain, isn't it?

As I cannot identify properly the usage of these fields, I just defined the boundary condition so you can define the value of sigma of the interface in the boundary itself (see the example bellow)

regA_to_regB
{
     type    potentialCoupledBaffleMixed;
     Tnbr   T;    // or the name of the potential field
     sigma 1000;   // The value of sigma in the regA
}

This sets the boundary condition to a fixed value in the interface. You have to define the boundary regB_to_regA as a potentialCoupledBaffleMixed, as well (and define a different value of sigma if you want).
For this to work you have to compile the code I attached bellow (I've tried on OF7, but it shall compile on OF6 as well) and add the resultant library on the controlDict:

libs            ("libpotentialcoupled.so");

Let me know any further problem you may have with this code!

Hi Carlos,

thank you for your fast reply! Let me answer a few questions at first.

- There are two electrical conductivities(sigma_e and sigma_H) because there are two electrical potential transport equations, one is proton H+ and the other is electron e-

- Yes, the electrical conductivities have different values along the domain.

However, there's error when I tried to wmake the code.

lan@lan-virtual-machine:~/OpenFOAM/lan-6/applications/potentialCoupledBaffleMixed_v1$ of6
lan@lan-virtual-machine:~/OpenFOAM/lan-6/applications/potentialCoupledBaffleMixed_v1$ wmake
wmakeLnIncludeAll: running wmakeLnInclude on dependent libraries:
wmakeLnInclude error: base directory ../turbulenceModels/ does not exist
g++ -std=c++11 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -O3 -DNoRepository -ftemplate-depth-100 -I../turbulenceModels/lnInclude -I/opt/openfoam6/src/transportModels/compressible/lnInclude -I/opt/openfoam6/src/thermophysicalModels/basic/lnInclude -I/opt/openfoam6/src/thermophysicalModels/specie/lnInclude -I/opt/openfoam6/src/thermophysicalModels/solidThermo/lnInclude -I/opt/openfoam6/src/thermophysicalModels/solidSpecie/lnInclude -I/opt/openfoam6/src/finiteVolume/lnInclude -I/opt/openfoam6/src/meshTools/lnInclude -IlnInclude -I. -I/opt/openfoam6/src/OpenFOAM/lnInclude -I/opt/openfoam6/src/OSspecific/POSIX/lnInclude -fPIC -c potentialCoupledBaffleMixedFvPatchScalarField.C -o Make/linux64GccDPInt32Opt/potentialCoupledBaffleMixedFvPatchScalarField.o
potentialCoupledBaffleMixedFvPatchScalarField.C: In member function ‘virtual void Foam:otentialCoupledBaffleMixedFvPatchScalarFiel d::write(Foam::Ostream&) const’:
potentialCoupledBaffleMixedFvPatchScalarField.C:23 8:37: error: no matching function for call to ‘Foam:otentialCoupledBaffleMixedFvPatchScalarFie ld::writeEntry(Foam::Ostream&, const char [5], const Foam::word&) const’
writeEntry(os, "Tnbr", TnbrName_);
^
In file included from /opt/openfoam6/src/OpenFOAM/lnInclude/labelField.H:39:0,
from /opt/openfoam6/src/OpenFOAM/lnInclude/primitiveFields.H:37,
from /opt/openfoam6/src/OpenFOAM/lnInclude/pointField.H:36,
from /opt/openfoam6/src/OpenFOAM/lnInclude/edge.H:40,
from /opt/openfoam6/src/OpenFOAM/lnInclude/edgeList.H:32,
from /opt/openfoam6/src/OpenFOAM/lnInclude/PrimitivePatch.H:56,
from /opt/openfoam6/src/OpenFOAM/lnInclude/primitivePatch.H:35,
from /opt/openfoam6/src/OpenFOAM/lnInclude/polyPatch.H:43,
from /opt/openfoam6/src/finiteVolume/lnInclude/fvPatch.H:39,
from /opt/openfoam6/src/finiteVolume/lnInclude/fvPatchField.H:47,
from /opt/openfoam6/src/finiteVolume/lnInclude/mixedFvPatchField.H:71,
from /opt/openfoam6/src/finiteVolume/lnInclude/mixedFvPatchFields.H:29,
from potentialCoupledBaffleMixedFvPatchScalarField.H:74 ,
from potentialCoupledBaffleMixedFvPatchScalarField.C:26 :
/opt/openfoam6/src/OpenFOAM/lnInclude/Field.H:355:14: note: candidate: void Foam::Field<Type>::writeEntry(const Foam::word&, Foam::Ostream&) const [with Type = double]
void writeEntry(const word& keyword, Ostream& os) const;
^~~~~~~~~~
/opt/openfoam6/src/OpenFOAM/lnInclude/Field.H:355:14: note: candidate expects 2 arguments, 3 provided
potentialCoupledBaffleMixedFvPatchScalarField.C:23 9:35: error: no matching function for call to ‘Foam:otentialCoupledBaffleMixedFvPatchScalarFie ld::writeEntry(Foam::Ostream&, const char [6], const scalar&) const’
writeEntry(os, "sigma", sigma_);
^
In file included from /opt/openfoam6/src/OpenFOAM/lnInclude/labelField.H:39:0,
from /opt/openfoam6/src/OpenFOAM/lnInclude/primitiveFields.H:37,
from /opt/openfoam6/src/OpenFOAM/lnInclude/pointField.H:36,
from /opt/openfoam6/src/OpenFOAM/lnInclude/edge.H:40,
from /opt/openfoam6/src/OpenFOAM/lnInclude/edgeList.H:32,
from /opt/openfoam6/src/OpenFOAM/lnInclude/PrimitivePatch.H:56,
from /opt/openfoam6/src/OpenFOAM/lnInclude/primitivePatch.H:35,
from /opt/openfoam6/src/OpenFOAM/lnInclude/polyPatch.H:43,
from /opt/openfoam6/src/finiteVolume/lnInclude/fvPatch.H:39,
from /opt/openfoam6/src/finiteVolume/lnInclude/fvPatchField.H:47,
from /opt/openfoam6/src/finiteVolume/lnInclude/mixedFvPatchField.H:71,
from /opt/openfoam6/src/finiteVolume/lnInclude/mixedFvPatchFields.H:29,
from potentialCoupledBaffleMixedFvPatchScalarField.H:74 ,
from potentialCoupledBaffleMixedFvPatchScalarField.C:26 :
/opt/openfoam6/src/OpenFOAM/lnInclude/Field.H:355:14: note: candidate: void Foam::Field<Type>::writeEntry(const Foam::word&, Foam::Ostream&) const [with Type = double]
void writeEntry(const word& keyword, Ostream& os) const;
^~~~~~~~~~
/opt/openfoam6/src/OpenFOAM/lnInclude/Field.H:355:14: note: candidate expects 2 arguments, 3 provided
/opt/openfoam6/wmake/rules/General/transform:25: recipe for target 'Make/linux64GccDPInt32Opt/potentialCoupledBaffleMixedFvPatchScalarField.o' failed

As far as my limited knowledge, I cannot understand the error. Could you have a look what it means?

Lan

[crubio.abujas]

Originally Posted by Lann

Hi Carlos,

thank you for your fast reply! Let me answer a few questions at first.

- There are two electrical conductivities(sigma_e and sigma_H) because there are two electrical potential transport equations, one is proton H+ and the other is electron e-

- Yes, the electrical conductivities have different values along the domain.

However, there's error when I tried to wmake the code.


As far as my limited knowledge, I cannot understand the error. Could you have a look what it means?

Lan

Ok, that was a silly mistake. As I told you I tried to compile in OF7. As I was a little bit lazy yesterday I never tried in OF6. Now I've installed this version and checked that writeEntry is introduced on OF7, so when you compile in OF6 it cannot find it.

Check this file adapted to OF6.

[Kombinator]

Originally Posted by crubio.abujas

Ok, that was a silly mistake. As I told you I tried to compile in OF7. As I was a little bit lazy yesterday I never tried in OF6. Now I've installed this version and checked that writeEntry is introduced on OF7, so when you compile in OF6 it cannot find it.

Check this file adapted to OF6.

Dear Carlos,

Firstly, thank you for sharing your work here. I also would like to use the interface condition for electrical potential and I find your BC very helpful. May I ask a question about how your BC treats sigma (electrical conductivity)? In my case, sigma is constant in the first domain and constant in the second domain but these constants are different from each other.

1. If I specify sigma as a scalar field in each domain, your BC changes sigma value at the interface, doesn't it? What in that case should I specify in the sigma field file for the interface BC: zeroGradient or calculated or something else?
2. Or your BC treats sigma as a constant from the transport properties file (each constant to each domain)?

Regards,
Artem

[crubio.abujas]

Hi Artem,

Glad to know my work can be useful for someone else, thank you for letting me know .

Concerning your question:

1. If I specify sigma as a scalar field in each domain, your BC changes sigma value at the interface, doesn't it? What in that case should I specify in the sigma field file for the interface BC: zeroGradient or calculated or something else?
2. Or your BC treats sigma as a constant from the transport properties file (each constant to each domain)?

The current implementation does neither. It uses sigma as a parameter of the boundary itself. You just need to set the value of sigma on the boundary condition, different on each of the regions, and the code shall use it to evaluate the boundary.

The approach 1 you're suggesting is interesting if sigma is changing along the domain and it is magnitudes are required for other calculation inside the region. The second approach you mention is the "correct" way to do it if sigma is a material property, just to be consistent with the structure of OF cases. As I do not know the precise nature of your calculation, I don't know if the approach 1 should be more interesting for you, so I went to the simpler solution I can imagine, although it may not be the most elegant solution.

Let me know if you got any further problems and I will see if I can find some time to improve the code.

Good luck!

[Kombinator]

Originally Posted by crubio.abujas

Hi Artem,

Glad to know my work can be useful for someone else, thank you for letting me know .

Concerning your question:
The current implementation does neither. It uses sigma as a parameter of the boundary itself. You just need to set the value of sigma on the boundary condition, different on each of the regions, and the code shall use it to evaluate the boundary.

The approach 1 you're suggesting is interesting if sigma is changing along the domain and it is magnitudes are required for other calculation inside the region. The second approach you mention is the "correct" way to do it if sigma is a material property, just to be consistent with the structure of OF cases. As I do not know the precise nature of your calculation, I don't know if the approach 1 should be more interesting for you, so I went to the simpler solution I can imagine, although it may not be the most elegant solution.

Let me know if you got any further problems and I will see if I can find some time to improve the code.

Good luck!

Thank you for the asnwer!