[maddalena]

This "WE" implies that there is someone else loosing sleeping hours for this as me???
Do you also need the solver? I will email them as soon as possible.

thanks

mad

[andrea]

Hi mad,
I've looked at it. The problem maybe the symmetry/zeroGradient condition on the left side of cube1, that makes T unbounded, while a fixedValue works. My advise will be to try a cube2-cube1-cube 2 configuration.

I opened this case and the tutorial, the cube case looks 10 times greater than it should be, but maybe is a paraview ocus-pocus.

let me know
Andrea

[maddalena]

Hello Andrea,

Originally Posted by andrea

The problem maybe the symmetry/zeroGradient condition on the left side of cube1, that makes T unbounded, while a fixedValue works.

Yes, that is true!!! It is unbelievable... The only things that I did not try yesterday... So, the solution seems to not use any symmetry BC...

Originally Posted by andrea

My advise will be to try a cube2-cube1-cube 2 configuration.

And this is the logical conclusion... Ok, I will report it as soon as possible.

Originally Posted by andrea

the cube case looks 10 times greater than it should be.

What does it mean? cube1 is a cube of 1 meter long. It seems to me that it is like that, no? Or did you compare it with the size of the tutorial? I have made them independently, so maybe I should scale my case to match the tutorial dimensions...
Thanks for your support, at least now I have a possible answer to the problem!
ciao

mad

[andrea]

cube1 is a cube of 1 meter long. It seems to me that it is like that, no? Or did you compare it with the size of the tutorial? I have made them independently, so maybe I should scale my case to match the tutorial dimensions...

yes I mean that they should be of the same order but open them in paraview makes look the cube 1o times bigger, mah!

Thanks for your support, at least now I have a possible answer to the problem!

I'm still not understanding why symmetry is not working!
ok

[maddalena]

Hello,

Originally Posted by andrea

My advise will be to try a cube2-cube1-cube 2 configuration.

guess what??? It is not working! I have the same results as the cube1-cube2 + symmetry.

but...

If I use a condition like the one shown in the attached figure... well, everything works! It seems like the solver needs a fixedValue somewhere in the domain to limit the heat source contribution...

Indeed...

coming back to the modified tutorial example. If you modify the minY BC from fixedValue 500K (or 300K) to zeroGradient BC, (and set U 0 0 0 in the fluid regions) well... The time vs temperature is ok in the first 100 simulated seconds, but it becomes linear after on!

Thus

it is not the "symmetry" or the "cyclic" or some special condition that does not work, but it is a "heat source limitation" problems.

I am going to think to it. Does it has any physical meaning connected with the BC we are fixing or is it a computational problem? What is your opinion on that?

mad

[andrea]

Hi,
I agree, but maybe is more subtle than this. Of course source should be limited, but putting a fixedValue on the left side of cube1 and putting zeroGradient on the right of cube2 just works fine... hence, in my opinion, coupling condition misbehaves...

Andrea

[maddalena]

Hi Andrea,

Originally Posted by andrea

putting a fixedValue on the left side of cube1 and putting zeroGradient on the right of cube2 just works fine...

yes, it works fine because we are limiting in some way the heat source... ant this limit is the fixedValue temperature on the left side of cube1.

One step more... I created a new case, like the cube2-cube1-cube2 case of yesterday and added a very large solid surrounding domain, where I fixed the temperature. Something similar is shown in the attached figure. In this case, we have NO BC on cube1, and its solution depends only on what is happening there. In addition, there is no involving convection, that may represent an additional problem. Now, we have two hypothesis on why the modified version of chtMultiRegionFoam fails:

1. BC that are not representing what we think.
2. coupling does not works properly.

If 1 is true, than the new case should work, since we have no BC on the heating region. If 2 is true, the new case should fail.

After running as usual, I have result as usual: linear time vs temperature, hence 2 is true and, as you suggested yesterday,

Originally Posted by andrea

coupling condition misbehaves.

What I cannot explain is why Robertas has a similar case over here, and she claims to have it running... Unfortunately, the case needs some modifications to run.

Therefore, we are at the same point of the 20th of July, when I started this thread. How to improve the coupling condition? Or, is there a way to limit the heat source without fixing the temperature on one side of it?

regards,

mad

[val46]

Hi mad,

I asked the OF support team about the heat source issue.
They told me I should take a look at the porousExplicitSourceReactingParcelFoam solver in OF-1.7.x
There is a energy source term in createExplicitSources.H:

Info<< "Creating energy source\n" << endl;
scalarTimeActivatedExplicitSourceList energySource
(
    "energy",
    mesh,
    dimEnergy/dimTime/dimVolume,
    "h"
);

I run the tutorial but I don't understand yet.

Regards,
Toni

[maddalena]

Ehi!

Originally Posted by val46

I asked the OF support team about the heat source issue.
They told me I should take a look at the porousExplicitSourceReactingParcelFoam solver in OF-1.7.x
There is a energy source term in createExplicitSources.H:

Well... thank you! It seems like you can receive support team help only by direct contact! Have they ever look at this thread??? mah...
Of course, I will have a look to it during the next week or so.
And please report everything. The three of us can do a good job, I hope...

mad

[maddalena]

Originally Posted by val46

There is a energy source term in createExplicitSources.H:

Hi Toni,
I looked at the file you pointed out. It seems that the createExplicitSources.H, which recalls timeActivateExplicitSource.H, is used only to define a heat source that can be activated / deactivated whenever you need it. In my case, the heat source is on and does not change for all the time, so this approach seems useless. Indeed the explicit source can be defined as I posted above.
In any case, Andrea and I found out that is the coupling condition that does not work properly when defining a heat source and not fix at least one of the boundary values. If the temperature is fixed in one of the boundaries, the heat source defined as above gives reasonable results.
The problem sounds deeper than it looks like. Hope I can still get some sort of support from the community, but at the moment none has suggested improvement for the coupling yet.
Regards,

mad

[Canesin]

Hi,

I will take a look at this also, can you send me the solver you have for now ??? You can send it to:
fc [at] canesin [dot] com

My problem is a little like yours, I have to add an heat source term that reads a variable cp and a variable value that both depends on another equation I solve in the domain.. (it is a triple coupled problem, magnetic+heat+fluid).

I will be back in here for the next developments of my solver... hope to work together.

[maddalena]

Just send it.

Originally Posted by Canesin

hope to work together.

Hope to work together too. I have been stuck to the same point for some weeks now.
Cheers,

maddalena

[maddalena]

Originally Posted by Canesin

I will be back in here for the next developments of my solver...

Hi Fabio, any news?

mad

[Canesin]

I have run a preprocessor in it and at the moment I'm trying to understand better the solver.
I agree it seams to do the interface like Patankar book.

[Canesin]

Originally Posted by maddalena

Hi Fabio, any news?

mad

I have added the source term explicit to the solid equation.. I will reproduce from memory the steps here, so I maybe type wrong some code.. I have changed little the solid, but a lot the fluid.. I'm trying to setup some validation cases now.. as soon as I do that will be back here.

tmp<fvScalarMatrix> TEqn
(
fvm::ddt(rho*cp, T)
- fvm::laplacian(K, T)
- S
);

Then added a field to it:
PrtList<volScalarField> Ss(solidRegions.size());

Ss.set
(
i,
new volScalarField,
IOobject ...
)
... In fact have copied temperature T field and just changed to "S".

Then I have changed the flow solver to a incompressible one and removed the PIMPLE loop to a PISO one... now I'm trying to validate with Blasius and planewall.. but I'm having some problems with mesh =/ ...

[phsieh2005]

Hi, Canesin,

I am interested in using incompressible solver for fluid in stead of the compressible solver in the current chtMultiRegionFoam solver. I am wondering if you can send me your solver so that I can learn from you?

What is your reason for using PISO instead of PIMPLE?

Pei

phsieh2005@yahoo.com

Originally Posted by Canesin

I have added the source term explicit to the solid equation.. I will reproduce from memory the steps here, so I maybe type wrong some code.. I have changed little the solid, but a lot the fluid.. I'm trying to setup some validation cases now.. as soon as I do that will be back here.

tmp<fvScalarMatrix> TEqn
(
fvm::ddt(rho*cp, T)
- fvm::laplacian(K, T)
- S
);

Then added a field to it:
PrtList<volScalarField> Ss(solidRegions.size());

Ss.set
(
i,
new volScalarField,
IOobject ...
)
... In fact have copied temperature T field and just changed to "S".

Then I have changed the flow solver to a incompressible one and removed the PIMPLE loop to a PISO one... now I'm trying to validate with Blasius and planewall.. but I'm having some problems with mesh =/ ...

[Canesin]

Originally Posted by phsieh2005

Hi, Canesin,

I am interested in using incompressible solver for fluid in stead of the compressible solver in the current chtMultiRegionFoam solver. I am wondering if you can send me your solver so that I can learn from you?

What is your reason for using PISO instead of PIMPLE?

Pei

phsieh2005@yahoo.com

Dier Phsieh,

I`m really sorry for not being able to send my solver.. I have an confidentiality agreement with the sponsor of my project .. But as soon as I have submited an paper to some journal I can publish some code here..

I have used an PISO loop because my problem is not steady-state, it has no steady-state configuration, it can be only determined an periodic developed region... In that case I use an PISO loop since PIMPLE is only to permit the use of large time-step, with don't make sence for me.. removing the PIMPLE to a PISO loop I can remove the outer loop (the "nOuterCorr" for loop) and improve the speedy of the solver.

[phsieh2005]

Thanks Canesin!

Pei

[swahono]

Hi Maddalena and Andrea,

Could you please show me how to compute the wall heat flux at every iteration when using the chtMultiRegionSimpleFoam (OF 1.7.0)?

I am a complete beginner with OpenFoam, and absolutely weak with C++.

Thank you very much.

Best Regards,
Stefano

[maddalena]

Originally Posted by swahono

Could you please show me how to compute the wall heat flux at every iteration when using the chtMultiRegionSimpleFoam (OF 1.7.0)?

Hi Stefano,
I commented the if selection while leaving uncommented the inner test in solidWallHeatFluxTemperature. Something like:

// if (debug)
//    {
      ...
      ...
//    }

Then recompiled the solver. The heat flux is written in the log file.

mad