Introductory Material is Absent

@timc0up were you able to run the taucha model through a few time steps and see anything in paraview? I put it through 260 time steps but I do not see anything similar to figure 6.5 in Geoenergy II. The slice looks like a normal gradient from surface to base - but the surface temperature is affecting the soil, nothing around a wellbore however. I wonder if the packaged mesh file is correct.

taucha - the attached files works for me:

taucha_bhe.zip (6.8 MB)

This is a windows version, which I run under wine; unzip wherever you wish.

Then, in the console enter either of these commands:
win: ogs.exe taucha (maybe run ogs.exe as administrator?)
linux: wine ./ogs taucha
make a coffee ā€¦

The main point is having all the taucha.* related files in the same folder as the ogs binary.
These taucha.* files are in windows format.

Until " Heat_Transport_BHE PipeNetwork Feature" is fixed, as I am no expert in this, the project files are only a reading exercise for me.
https://www.opengeosys.org/docs/userguide/process-dependent-configuration/heat_transport_bhe_pipelinenetwork/

If it fails the test and there is no response to fixing it, then I donā€™t persevere with that data model.

In the meanwhile I have installed and tested OK the MOOSE::FALCON platform,

https://mooseframework.inl.gov/falcon/getting_started/installation/index.html

which is dedicated to the geothermal engineering based on the Utah FORGE project. It is a bit arcane to install, let me know if you run into problems. They have interesting geothermal-related economic modules, which might appeal to your area of interest.

Yes, this works. It takes a very long time to run anything significant for me. I did see there is an obsolete solver in use for the Taucha files. I am not sure how long Haibing was running OGS to arrive at figure 6.5. Probably many coffees.

I think we are on the same plane in terms of expectations and frustation with OGS 5 and OGS 6 BHE /TESPy side of things. To get interest in OGS 6, the simulation needs to produce meaningful results. Although I suspect you havenā€™t succeeded with that one either?

In relation to OGS 5, It stands to reason that porting the excellent tutorials published online for OGS 5 should have been ported to OGS 6 in a workable fashion; once again implying that testing produces meaningful results. The necessity is simple, individuals learn from successful templates that can be adapted, full or partial, to their problem space.

Here is a comment from a potential user on researchgate, where the problem for beginners with opengeosys does sound familiar:

Marwan Fahs

University of Strasbourg

OpenGeosys [https://www.opengeosys.org/]

Anna Uciechowska-Grakowicz, Wroclaw University of Science and Technology

[Marwan Fahs] this software looks very cool, but it looks very hard as well, do you know any tutorials for current version for beginners (like opening the program, setting up a model etc)? These on website doesnā€™t help a lot, Iā€™ve even given up trials to open itā€¦

ā€œIā€™ve even given up trials to open itā€¦ā€

In the mean time, the coffee is good ā€¦

1 Like

There are a few things I wonder about this. It is a bummer that the volumetric flow rate needs a specification at the outset. I would think this could simply be inferred from the load or demand placed upon the heat pump on the supply side. This is how the TESPy heat pumps usually run. Otherwise we are talking about a scenario where the specifications must already be known. More advantageous would be specifying the load then allowing the TESPy OGS interface to dimension system components in the solver to that effect.

Perhaps I am misinterpreting the docs, however.

To be frank, I havenā€™t looked at this in detail, apart from testing and drawing comparisons with other open source software that have excellent tutorials and support for researchers wanting to be productive.

I am following you on this one, as it is your area of expertise.

Can you explain what is wrong with it? This model is part of our continous testing and is run several times a day on several machines (including 3 major operating systems).

@bilke as above, responses 15, 16, 17/28

I saw that you had it passing the tests;
if that meant ithe simulation ran, then yes, so did mine.

However the unresolved issue is the unexpected results, identified by Chaofan.
The saved data and output are attached for the OGS 6.4 simulation.

So the question is, if the test ran OK without errors; what do the results represent?

I donā€™t think the answer will be difficult to find, eventually, and I should be able to rerun the simulation to produce the expected results. That should be the outcome of this episode.

####################################################

Ok, got it! Then maybe @Chaofan @HBShao or @ShuangChen should have a look on this!


FYI: In the future we would like to create the benchmark documentation pages from a running Jupyter Notebook which would ensure that the whole workflow and especially the figures in the docs are really the result of the actual simulation code. See the following page for an early prototype of the functionality: https://www.opengeosys.org/docs/benchmarks/notebooks/simplemechanics/

@bilke: thatā€™s a very good idea! I will look at your prototype.

Regarding the unexpected results, I am using v6.4.0 which I compiled myself on Ubuntu.
I mention this in case it has a role to play in the discrepancy.

@bilke I am trying to switch to OGS 6 now. It is working with bindings on 3.7.2, but it will not run the .prj for this benchmark. In CLI, I keep getting a PARSE ERROR
Argument: of
Couldnā€™t find match for argument

I have poetry installed as required in the read me. I also have Python 3.8 installed for TESPy and it runs stand alone fine. Why would OGS6 not be able to open the .prj? This error sounds like a Python problem.

Full command you execute and its corresponding output please.

C:\Windows\system32>ogs C:\Users\nicho\Desktop\University of North Dakota\OpenGeoSys Manuals\Geoenergy Modeling II\OGS6\borehole_HEX_DH\3D_3BHEs_array\3bhes_1U.prj
PARSE ERROR: Argument: of
             Couldn't find match for argument

Brief USAGE:
   ogs  [--unbuffered-std-out] [--config-warnings-nonfatal] [-l
        <LOG_LEVEL>] [-o <PATH>] [-p <>] ... [-r <PATH>] [--] [--version]
        [-h] <PROJECT_FILE>

For complete USAGE and HELP type:
   ogs --help

You need to put the path in quotes.

Silly me. Thanks. Any thoughts on this error?

C:\Program Files\Python37>ogs "C:\Users\nicho\Desktop\University of North Dakota\OpenGeoSys Manuals\Geoenergy Modeling II\OGS6\borehole_HEX_DH\3D_3BHEs_array\3bhes_1U.prj"
info: This is OpenGeoSys-6 version 6.4.1.
info: OGS started on 2021-11-02 08:09:20-0500.
warning: Consider switching from mesh and geometry input to multiple meshes input. See https://www.opengeosys.org/docs/tools/meshing-submeshes/constructmeshesfromgeometry/ tool for conversion.
warning: PointVec::PointVec(): there are 2 double points.
3.7.2 (tags/v3.7.2:9a3ffc0492, Dec 23 2018, 23:09:28) [MSC v.1916 64 bit (AMD64)]
error: KeyError: 'comp_type'

At:
  C:\Program Files\Python37\lib\site-packages\pandas\core\indexes\base.py(3363): get_loc
  C:\Program Files\Python37\lib\site-packages\pandas\core\series.py(1051): _get_value
  C:\Program Files\Python37\lib\site-packages\pandas\core\series.py(942): __getitem__
  C:\Program Files\Python37\lib\site-packages\tespy\networks\network_reader.py(406): construct_comps
  C:\Program Files\Python37\lib\site-packages\pandas\core\apply.py(131): f
  C:\Program Files\Python37\lib\site-packages\pandas\core\apply.py(832): apply_series_generator
  C:\Program Files\Python37\lib\site-packages\pandas\core\apply.py(812): apply_standard
  C:\Program Files\Python37\lib\site-packages\pandas\core\apply.py(688): apply
  C:\Program Files\Python37\lib\site-packages\pandas\core\frame.py(8740): apply
  C:\Program Files\Python37\lib\site-packages\tespy\networks\network_reader.py(310): load_network
  C:\Users\nicho\Desktop\University of North Dakota\OpenGeoSys Manuals\Geoenergy Modeling II\OGS6\borehole_HEX_DH\3D_3BHEs_array\bcs_tespy.py(171): <module>

info: OGS terminated on 2021-11-02 08:09:23-0500.
error: OGS terminated with error.

I guess you will need some additional Python modules installedā€¦

@ShuangChen Can you give some advice here?

@timc0up @NicholasFry @bilke @Chaofan Sorry for the very delay of the replyā€¦

@timc0up Thanks for your comment. In fact, there are indeed some places are not details described and explained in the documentation of benchmark ā€˜A 3-BHE Array Coupled With Pipe Networkā€™. So it causes some confusions in the benchmark results as you found, which makes me feel sorry about that. 1) Firstly regarding the 41-42 degC problem. In fact in this benchmark, we have set our model initial temperature BC with an additionally +30 degC. So it is why in the documentation it says the initial domain is 12 degC but in fact in the related prj file(ā€¦/Tests/Data/Parabolic/T/3D_3BHEs_array/3bhes_1U.prj) at line 282 you see the T0 is set to 315.15 K(42 degC). The lack of the information in the documentation is really a mistakeā€¦ The reason why to set like this way is to avoid the tespy solver failing if the circulation flow temperature is computed to approaching 0 (caused by enthalpy calcualtion error in CoolProp for water). It seems not so reasonable, but we firstly used this +30 degC BC to terminate the simulation. And in the results stage we subtract then this 30 degC to soil Temperature results and also the calculated flow temperature results. These lead to the related temperature figure results in the documentation showed with soil T>8~11 degC and in/out flow T> -5~0 degC. 2) Regarding the unchanged soil temperature. If I understood right, based on the Output_bcs_tespy.zip file which you attached, you have only simulated your model with 600 seconds. In fact, all the results showed in the documentation are computed from a full time simulation, which is noted at line 237~238 in the prj file ((ā€¦/Tests/Data/Parabolic/T/3D_3BHEs_array/3bhes_1U.prj).

@NicholasFry Regarding the ā€˜comp_typeā€™ error. I can only get some guess of the reason. 1ļ¼‰Please check if the tespy version is 0.3.2. 2) Seems the error due to the pandas module. If possible, try to delete the pandas module firstly and then ā€˜pip install tespy==0.3.2ā€™ to re-download the related pandas version suit for tespy0.3.2.

Best regards,
Shuang

1 Like

@ShuangChen Thank you. It was a version problem with TESPy that caused the error. It also appears that the closed loop variant in the benchmark download specifies a path for TESPy components that are not included.

C:\Program Files\Python37>ogs "C:\Users\nicho\Desktop\University of North Dakota\OpenGeoSys Manuals\Geoenergy Modeling II\OGS6\borehole_HEX_DH\3D_3BHEs_array\3bhes_1U.prj"
info: This is OpenGeoSys-6 version 6.4.1.
info: OGS started on 2021-11-02 14:23:44-0500.
warning: Consider switching from mesh and geometry input to multiple meshes input. See https://www.opengeosys.org/docs/tools/meshing-submeshes/constructmeshesfromgeometry/ tool for conversion.
warning: PointVec::PointVec(): there are 2 double points.
3.7.2 (tags/v3.7.2:9a3ffc0492, Dec 23 2018, 23:09:28) [MSC v.1916 64 bit (AMD64)]
Project dir is:  C:\Program Files\Python37
error: FileNotFoundError: [WinError 3] The system cannot find the path specified: '.\\pre\\tespy_nw_closedloop\\components\\'

In your output it shows the Project dir is C:\Program Files\Python37. Is your test file also located in that path? Because the tespy components in the ./pre folder can only be found, when the project direction is set to the path where the prj file (also the ./pre folder) is located.