We know that OGS currently includes 1U, 2U, CXA and CXC BHE configurations. Is it possible to model a W-type loop in OGS, or approximate it using existing configurations?
We need to calculate inflow and outflow temperatures for a case using W-loops — what would be the most accurate modelling approach? Has anyone implemented something close to a W-loop or found a recommended workaround?
See picture below, and thanks for any help.
The BHE process in the OGS is using dual-continuum method, all the components inside the borehole (pipes, grout, circulation fluid) of 1U, 2U, CXA, CXC are simulated in line elements. This does not work in your case.
One possible way is to fully discretized all the components inside the borehole of the W-type loop, pipes, grout, circulation fluid, etc. Then the HT (Hydro-thermal) process can be used instead of the BHE process.
Best regards,
Chaofan Chen
Hi @Chaofan
Thank you for the clarification.
Do you know of any example projects or benchmark cases using the HT (Hydro-thermal) process that include explicitly modelled pipes or similar setups which could be used as inspiration?
Any reference PRJ files or links would be very helpful.
There is no benchmark case specific to pipes heat transport, but you can find current benchmark cases of HT process (prj files) in this folder: Tests/Data/Parabolic/HT · master · ogs / ogs · GitLab
The difficulty of modeling your W loop BHE is the mesh construction, every component inside the borehole has to be meshed and impose individual material ID to give specific porous media parameters, e.g., for circulation fluids mesh, the velocity should be very high (to achieve this, you can give a very higher permeability of the porous media corresponding to the mesh/material ID) and the process of the pipe wall is dominated only by heat conduction, so for that material, no velocity is needed, you can give a very low permeability… etc. Similar to this, give all different parameters for different parts of the meshes with porous media properties under specific material IDs. The system should be simulated.
The depth of the W BHE in your figure is just 23/24 m, so fully discretized model should work in my opinion. Have fun with modeling BHE!
Best regards,
Chaofan
I know that a BHE simulation with a HT process was performed by Bookmeyer and Beier Efficient simulation of multiple borehole heat exchanger storage sites | Environmental Earth Sciences | Springer Nature Link - I guess with OGS5, the former version of OGS. Therefore it is maybe an interesting source for the modeling idea but not for the specific prj-file.
Another idea I get in mind is to maybe simulate two very close 1U BHEs and assign the condition that T_out of BHE1 is T_in of BHE2 maybe via an iterative procedure in the python boundary condition. Between the two 1U BHEs you will fully discretize the borehole and assign an own materialID for the grout properties. Maybe this can save some elements, due to not discretize the pipes. @Chaofan What do you think?
To develop an own thermal resistance capacity model (TRCM) for this W BHE will be a lot of work and needs also verification, if it is works properly. With a TRCM, it will be possible to implement the W-Type like the other BHE types in OGS.
Best regards, Max
Hi @M_Jaeschke and @Chaofan ,
Thank you very much for the helpful suggestions, this clarified a lot for us.
We are planning to proceed with modelling the W-loop as two very close 1U BHEs in series, where T_out of BHE1 becomes T_in of BHE2, as you suggested.
At the moment, we are only running OGS via the command line using the standard executable, so we would really appreciate any tips or guidance on how this iterative coupling could be implemented in Python.
Thanks again for your help!
Best regards,
Andreas
the python boundary condition for the BHEs is not that well documented and personally I’m not that familiar with. I think @Chaofan knows it in more detail. We have this Tespy benchmark on the website: A 3-BHE Array Coupled With Pipe Network
This is more complex than you need it, all files for this can be found in this folder: Tests/Data/Parabolic/T/3D_3BHEs_array · 6.5.7 · ogs / ogs · GitLab (Some input syntax for the BHE FlowAndTemperatureControl was changed in the current ogs master, I guess you use ogs6.5.7 and therefore this folder should be fine for now.)
The most important part is the <python_script> and the <use_bhe_pipe_network>in the prj-file, see here: Tests/Data/Parabolic/T/3D_3BHEs_array/3bhes_1U.prj · 6.5.7 · ogs / ogs · GitLab
In the python script the class BC is the important one and all functions with exactly this names are needed. I also think, that the init of this class in the last line is necessary. In the TespySolver function you should be able to set the T_out1 == T_in2 and control the convergence with the if_success bool.
Good luck and just ask again, if you encounter problems.
Best regards,
Max
Great discussion and brainstorming @M_Jaeschke and @Andreas_Kubberod.
Or the normal Python boundary condition can be directly used to achieve
T_out of BHE1 becomes T_in of BHE2
During every iteration, reading the T_out of BHE1, impose it to T_in of BHE2 in python bc. The usage of Python bc can be easily checked in the benchmarks gallery, e.g., Tests/Data/Parabolic/ComponentTransport/elder · 6.5.7 · ogs / ogs · GitLab
Only one small issue, when meshing the two very closed 1U BHEs, please notice the mesh between them, to check if it is needed to satisfy the mesh regulation in Diersch’s book. From my side, I think if there is no temperature oscillation, we don’t need to follow the mesh regulation around the BHE as this 1U is not installed in an independent well.
Looking forward to the simulation results!
Best regards,
Chaofan
