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 --helpYou 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.
@Shuang, many thanks for replying and to clarify the documentation!
Have I correctly amended lines 237~238 in the prj file?
i.e the succession (eight lines) of “repeat …delta_t” ?
<time_stepping>
<type>FixedTimeStepping</type>
<t_initial> 0.0 </t_initial>
<!-- use the following for full simulation
<t_end> 15552000 </t_end>
-->
<t_end> 15552000 </t_end>
<timesteps>
<!-- use the following for full simulation
</pair>
<repeat>10</repeat>
<delta_t>60</delta_t>
<repeat>1</repeat>
<delta_t>3000</delta_t>
<repeat>5</repeat>
<delta_t>3600</delta_t>
<repeat>1</repeat>
<delta_t>10800</delta_t>
</pair>
<!-- <pair>
<repeat>10</repeat>
<delta_t>60</delta_t>
</pair>
-->
</timesteps>
</time_stepping>
I will read through your answer for 1) regarding the 41-42 degC problem.
Intuitively I can follow the logic,
but I am uncertain as to what I should be changing to get the correct result?
@timc0up Seems partly correct. Maybe a simple way is just to remove the following lines in your command:
<!-- use the following for full simulation
…
</pair> <!-- <pair> <repeat>10</repeat> <delta_t>60</delta_t> </pair> -->
Regarding the 1), the logic here is that the model is assumed with a +30 degC for all BCs at the beginning. When simulation is terminated, all results need to be subtracted by 30 degC again.
The open loop runs with this same command. You are right for the closed loop variant. It will only run if I navigate to the .prj folder, even though I call it in CLI. I guess the open loop version is accessing the pre folder differently.
The test for “3-BHE Array Coupled With Pipe Network” (i.e. 3bhes_1U.prj) has run OK without errors for full simulation of 180 days (15552000 seconds).
Soil temperature range over 180 days is now 9.6 degC (9.637 degC)
Following the advice from @ShuangChen , to subtract 30 degC from the results:
temperature soil [306.209, 315.846] degKelvin
temperature soil [33.059, 42.696] degCelsius
temperature soil [3.059, 12.696] degCelsius adjusted (subtract 30)
temperature BHE1 [0, 299.9], [0, 300.63], [0, 308.314], [0, 308.314]
temperature_BHE2 [0, 299.864], [0, 300.562], [0, 308.071], [0, 308.071]
temperature_BHE3 [0, 299.9], [0, 300.63], [0, 308.314], [0, 308.314]
@ShuangChen – I have attached the results and the amended .prj file if you would like to comment further. The amended .prj file is there for anyone else who wants to run the full simulation, using OpenGeoSys v6.4 on Ubuntu 20.04, described here:
Updating the documentation for “3-BHE Array Coupled With Pipe Network” would be helpful. Especially given the anomaly when using tespy, if the flow temperatures approach zero:
3bhes_1U_results.zip (3.3 MB)
Thanks
@timc0up Thank you for your feedback. I have looked into your attached results and it seems the results are fine. Your suggestion to update the benchmark documentation is really sinnvoll to us. I will make some updating on it as soon as I can.
Best regards,
Shuang
Hi Shuang,
A big thank you to you also and taking the time to explain your very helpful insights into the rationale behind this Benchmark. This makes a big difference for beginners such as myself in understanding how to use OpenGeoSys.
@NicholasFry @timc0up Updated documentation of the benchmark is already available online. Hope it helps a better understanding of the benchmark.
Thank you for your questions and feedbacks.
Best regards,
Shuang