# Version request

Dear OGS developers,

I would like to merge our implementation into the trunk.

The major changes:

1.   Coupled THM time controlled excavation.

2.   Neglect H initial effect


According to the effective stress concept the balance equation for DEFORMATION process is written as:

(1)

In current OGS it is implemented as the increment from the initial stress state, and has the form:

(2)

where,
is the initial stress tensor,
and is the current stress tensor and pore pressure. Apparently the initial state of pore water pressure is not considered. But, sometimes it is necessary, e.g. for coupled HM modelling of excavation process. Thus, we modify the equation to the following form:

(3)

A new sub-keyword is introduced, and users can flexibly choose between Eq.2 and Eq.3.

1.   Anisotropic plasticity with Mohr-Coulomb criterion


A benchmark with description in details will be uploaded later.

1.   Dependence between storage coefficient and the minimum principal stress

2.   Automatically calculate storage coefficient from the stiffness parameters (Young’s modulus, Poisson ratio) of anisotropic material by the coupled LIQUID_FLOW and DEFORMATION modelling.


If there is no objection, I will update the trunk next week. Some benchmarks will be uploaded when the version release is done.

With best regards,

Wenjie

image001.wmz (778 Bytes)

image003.wmz (842 Bytes)

image005.wmz (555 Bytes)

image007.wmz (556 Bytes)

image009.wmz (526 Bytes)

image011.wmz (874 Bytes)

oledata.mso (3.96 KB)

Dear Wenjie,

The changes are great. I only have one suggestion regarding to 2:
Do not allocate the memory or set variable for p_0^w, and directly add \alpha p_0^w I to stress0 as
STRESS0 -= \alpha (S^w*p_0^w + S^g*p_0^g) I.
If you did not do this way, you can skip to apply your change 2 (Neglect H initial effect) because I implemented that addressed above recently.

Best,

Wenqing

···

On 05.04.2013 10:19, Xu, Wenjie wrote:

Dear OGS developers,

I would like to merge our implementation into the trunk.

The major changes:

1.Coupled THM time controlled excavation.

2.Neglect H initial effect

According to the effective stress concept the balance equation for DEFORMATION process is written as:

(1)

In current OGS it is implemented as the increment from the initial stress state, and has the form:

(2)

where, is the initial stress tensor, and is the current stress tensor and pore pressure. Apparently the initial state of pore water pressure is not considered. But, sometimes it is necessary, e.g. for coupled HM modelling of excavation process. Thus, we modify the equation to the following form:

(3)

A new sub-keyword is introduced, and users can flexibly choose between Eq.2 and Eq.3.

3.Anisotropic plasticity with Mohr-Coulomb criterion

A benchmark with description in details will be uploaded later.

4.Dependence between storage coefficient and the minimum principal stress

5.Automatically calculate storage coefficient from the stiffness parameters (Young's modulus, Poisson ratio) of anisotropic material by the coupled LIQUID_FLOW and DEFORMATION modelling.

If there is no objection, I will update the trunk next week. Some benchmarks will be uploaded when the version release is done.

With best regards,

Wenjie

--
You received this message because you are subscribed to the Google Groups "ogs-devs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ogs-devs+unsubscribe@googlegroups.com.

These are for fixing the broken tool that can convert the recharge data (in GIS shape syntax, e.g. from mHM) to node-wise sources for the FEM.

Wenqing

diff.pdf (44.5 KB)

I don't quite see in which case these changes make sense. You basically remove the mesh_grid completely when the preprocessor directive is set. I don't see the reason for that because even if you don't need it, it's just a nullptr. On the other hand the missing grid might result in problems elsewhere.
Also, why the new write method?

Finally, please note that what your are always referring to as "shape files" are actually *not* shape files but raster files. For someone working with both types of data/files, using the wrong nameis very confusing.

--Karsten

···

Am 04.03.2014 17:24, schrieb Wenqing Wang:

These are for fixing the broken tool that can convert the recharge data (in GIS shape syntax, e.g. from mHM) to node-wise sources for the FEM.

Wenqing

--

Dr. Karsten Rink
Department of Environmental Informatics
Helmholtz Centre for Environmental Research - UFZ
Permoserstrasse 15, 04318 Leipzig, Germany
Tel: +49(0)-341-235-1067
e-mail: karsten.rink@ufz.de

What exactly was broken? From the diff I can not see which error is fixed.

You introduce a new switch to the cmake file. Why didn't you use the existing OGS_BUILD_UTILITIES?

···

On 03/04/2014 05:24 PM, Wenqing Wang wrote:

fixing the broken tool

--
Dr. Thomas Fischer

Department of Environmental Informatics
Helmholtz Centre for Environmental Research GmbH - UFZ
Permoserstraße 15 / 04318 Leipzig / Germany
Tel.: +49 341 235 - 1054 / Fax: +49 341 235 - 1939
thomas.fischer@ufz.de / http://www.ufz.de

Helmholtz-Zentrum für Umweltforschung GmbH - UFZ
Sitz der Gesellschaft: Leipzig
Registergericht: Amtsgericht Leipzig, Handelsregister Nr. B 4703
Vorsitzender des Aufsichtsrats: MinDirig Wilfried Kraus
Wissenschaftlicher Geschäftsführer: Prof. Dr. Georg Teutsch

I don't quite see in which case these changes make sense. You basically remove the mesh_grid completely when the preprocessor directive is set. I don't see the reason for that because even if you don't need it, it's just a nullptr. On the other hand the missing grid might result in problems elsewhere.

The reason is that the small tool only involves several classes and does not needs GeoLib at all. Otherwise, there would many unused classes involved in that small tool. The preprocessor is only for that tool.

Also, why the new write method?

There was a writing function to dump mesh into an ogs syntax mesh file before but it was removed. The tool needs it.

Finally, please note that what your are always referring to as "shape files" are actually *not* shape files but raster files. For someone working with both types of data/files, using the wrong nameis very confusing.

Will be changed.

···

On 05.03.2014 10:52, Karsten Rink wrote:

--Karsten

Am 04.03.2014 17:24, schrieb Wenqing Wang:

These are for fixing the broken tool that can convert the recharge data (in GIS shape syntax, e.g. from mHM) to node-wise sources for the FEM.

Wenqing

fixing the broken tool

What exactly was broken? From the diff I can not see which error is fixed.

A tool to convert recharge data in raster file to node-wises source for the FEM. Its cmake configuration was standalone before and it was not updated along with the change of mesh classes.

You introduce a new switch to the cmake file. Why didn't you use the existing OGS_BUILD_UTILITIES?

In order that it can be complied without QT involved.

···

On 05.03.2014 11:04, Thomas Fischer wrote:

On 03/04/2014 05:24 PM, Wenqing Wang wrote:

So this was a standalone tool. Now you integrated it to the trunk. So there was no error within the OGS-5 trunk code? I was confused because from your first e-mail I got the impression something in the code was broken und you fixed it.

···

On 03/05/2014 11:21 AM, Wenqing Wang wrote:

A tool to convert recharge data in raster file to node-wises source for
the FEM. Its cmake configuration was standalone before and it was not
updated along with the change of mesh classes.

--
Dr. Thomas Fischer

Department of Environmental Informatics
Helmholtz Centre for Environmental Research GmbH - UFZ
Permoserstraße 15 / 04318 Leipzig / Germany
Tel.: +49 341 235 - 1054 / Fax: +49 341 235 - 1939
thomas.fischer@ufz.de / http://www.ufz.de

Helmholtz-Zentrum für Umweltforschung GmbH - UFZ
Sitz der Gesellschaft: Leipzig
Registergericht: Amtsgericht Leipzig, Handelsregister Nr. B 4703
Vorsitzender des Aufsichtsrats: MinDirig Wilfried Kraus
Wissenschaftlicher Geschäftsführer: Prof. Dr. Georg Teutsch

It has been in the trunk long time before, but its cmake configuration is not included in the root CMakeLists.txt and thus it was not tested with every commit.

···

On 05.03.2014 11:35, Thomas Fischer wrote:

On 03/05/2014 11:21 AM, Wenqing Wang wrote:

A tool to convert recharge data in raster file to node-wises source for
the FEM. Its cmake configuration was standalone before and it was not
updated along with the change of mesh classes.

So this was a standalone tool. Now you integrated it to the trunk. So there was no error within the OGS-5 trunk code? I was confused because from your first e-mail I got the impression something in the code was broken und you fixed it.

You introduced some preprocessor directives that is only used for *one special case* but makes reading the code *much harder* in general?

···

On 03/05/2014 11:16 AM, Wenqing Wang wrote:

The reason is that the small tool only involves several classes and does
not needs GeoLib at all. Otherwise, there would many unused classes
involved in that small tool. The preprocessor is only for that tool.

--
Dr. Thomas Fischer

Department of Environmental Informatics
Helmholtz Centre for Environmental Research GmbH - UFZ
Permoserstraße 15 / 04318 Leipzig / Germany
Tel.: +49 341 235 - 1054 / Fax: +49 341 235 - 1939
thomas.fischer@ufz.de / http://www.ufz.de

Helmholtz-Zentrum für Umweltforschung GmbH - UFZ
Sitz der Gesellschaft: Leipzig
Registergericht: Amtsgericht Leipzig, Handelsregister Nr. B 4703
Vorsitzender des Aufsichtsrats: MinDirig Wilfried Kraus
Wissenschaftlicher Geschäftsführer: Prof. Dr. Georg Teutsch

These preprocessor directives were introduced before. I only use one to exclude 'Grid'.

···

On 05.03.2014 11:42, Thomas Fischer wrote:

On 03/05/2014 11:16 AM, Wenqing Wang wrote:

The reason is that the small tool only involves several classes and does
not needs GeoLib at all. Otherwise, there would many unused classes
involved in that small tool. The preprocessor is only for that tool.

You introduced some preprocessor directives that is only used for *one special case* but makes reading the code *much harder* in general?

So it was not compiled, tested, benchmarked long time? Was it ever compiled, tested or benchmarked in the official trunk version?

···

On 03/05/2014 11:37 AM, Wenqing Wang wrote:

It has been in the trunk long time before, but its cmake configuration
is not included in the root CMakeLists.txt and thus it was not tested
with every commit.

--
Dr. Thomas Fischer

Department of Environmental Informatics
Helmholtz Centre for Environmental Research GmbH - UFZ
Permoserstraße 15 / 04318 Leipzig / Germany
Tel.: +49 341 235 - 1054 / Fax: +49 341 235 - 1939
thomas.fischer@ufz.de / http://www.ufz.de

Helmholtz-Zentrum für Umweltforschung GmbH - UFZ
Sitz der Gesellschaft: Leipzig
Registergericht: Amtsgericht Leipzig, Handelsregister Nr. B 4703
Vorsitzender des Aufsichtsrats: MinDirig Wilfried Kraus
Wissenschaftlicher Geschäftsführer: Prof. Dr. Georg Teutsch

There is no benchmark for that, but it could be compiled and run before.

···

On 05.03.2014 11:44, Thomas Fischer wrote:

On 03/05/2014 11:37 AM, Wenqing Wang wrote:

It has been in the trunk long time before, but its cmake configuration
is not included in the root CMakeLists.txt and thus it was not tested
with every commit.

So it was not compiled, tested, benchmarked long time? Was it ever compiled, tested or benchmarked in the official trunk version?

Hi Wenqing,

I see your point for introducing the new directive + write method.
However, in the compiled tool there are no "unused classes". Whatever is not needed is not compiled/linked into the final application, so it really makes no sense to re-implement functionality in order to not include GeoLib or FileIO.
Specifically, OGS_BUILD_UTILITIES does not necessarily require Qt.

@TomFischer also makes an excellent point: for this one tool you made parts of the mesh class more difficult to understand. For one thing, there is now the preprocessor directive which makes every instance where the grid-class is mentioned two lines longer. The other thing is that it is not immediately clear what the directive actually means or when it is used/not used.
I would *really* like to urge you to remove the directive again.
As for the write-method: This is basically duplicate code. I would not care if it was inside your tool but as far as I can see it is in the mesh-class itself, which again makes things more confusing because you have to find out which method is called under certain circumstances. So if you absolutely want to keep it, please move it into your utility.

Best,
Karsten

···

Am 05.03.2014 11:21, schrieb Wenqing Wang:

On 05.03.2014 11:04, Thomas Fischer wrote:

On 03/04/2014 05:24 PM, Wenqing Wang wrote:

fixing the broken tool

What exactly was broken? From the diff I can not see which error is fixed.

A tool to convert recharge data in raster file to node-wises source for the FEM. Its cmake configuration was standalone before and it was not updated along with the change of mesh classes.

You introduce a new switch to the cmake file. Why didn't you use the existing OGS_BUILD_UTILITIES?

In order that it can be complied without QT involved.

--

Dr. Karsten Rink
Department of Environmental Informatics
Helmholtz Centre for Environmental Research - UFZ
Permoserstrasse 15, 04318 Leipzig, Germany
Tel: +49(0)-341-235-1067
e-mail: karsten.rink@ufz.de

I have the concern that introducing the previous existing directive to other places within the code can break other configurations. For what reason the directive was used before? How can be ensured that using the directive at new, additional places in the code has no side effects?

Nevertheless the use of preprocessor directives make code *much harder* to read.

···

On 03/05/2014 11:41 AM, Wenqing Wang wrote:

These preprocessor directives were introduced before. I only use one to
exclude 'Grid'.

--
Dr. Thomas Fischer

Department of Environmental Informatics
Helmholtz Centre for Environmental Research GmbH - UFZ
Permoserstraße 15 / 04318 Leipzig / Germany
Tel.: +49 341 235 - 1054 / Fax: +49 341 235 - 1939
thomas.fischer@ufz.de / http://www.ufz.de

Helmholtz-Zentrum für Umweltforschung GmbH - UFZ
Sitz der Gesellschaft: Leipzig
Registergericht: Amtsgericht Leipzig, Handelsregister Nr. B 4703
Vorsitzender des Aufsichtsrats: MinDirig Wilfried Kraus
Wissenschaftlicher Geschäftsführer: Prof. Dr. Georg Teutsch

Hi Wenqing,

I see your point for introducing the new directive + write method.
However, in the compiled tool there are no "unused classes". Whatever is not needed is not compiled/linked into the final application, so it really makes no sense to re-implement functionality in order to not include GeoLib or FileIO.

OK

Specifically, OGS_BUILD_UTILITIES does not necessarily require Qt.

OK

@TomFischer also makes an excellent point: for this one tool you made parts of the mesh class more difficult to understand. For one thing, there is now the preprocessor directive which makes every instance where the grid-class is mentioned two lines longer. The other thing is that it is not immediately clear what the directive actually means or when it is used/not used.
I would *really* like to urge you to remove the directive again.

OK

As for the write-method: This is basically duplicate code. I would not care if it was inside your tool but as far as I can see it is in the mesh-class itself, which again makes things more confusing because you have to find out which method is called under certain circumstances. So if you absolutely want to keep it, please move it into your utility.

There is not writing function in mesh class. The function is in that tool.

···

On 05.03.2014 12:18, Karsten Rink wrote:

Best,
Karsten

Am 05.03.2014 11:21, schrieb Wenqing Wang:

On 05.03.2014 11:04, Thomas Fischer wrote:

On 03/04/2014 05:24 PM, Wenqing Wang wrote:

fixing the broken tool

What exactly was broken? From the diff I can not see which error is fixed.

A tool to convert recharge data in raster file to node-wises source for the FEM. Its cmake configuration was standalone before and it was not updated along with the change of mesh classes.

You introduce a new switch to the cmake file. Why didn't you use the existing OGS_BUILD_UTILITIES?

In order that it can be complied without QT involved.

Removed two pre-processor directives that had added before. Now the accessory tools have to be compiled with two options together:
OGS_BUILD_UTILITIES and any of the FEM options, e.g.
-DOGS_BUILD_UTILITIES=ON -DOGS_FEM=ON

The compilation takes longer time if these options are chosen, but one can get a series useful tools in 'bin' sub-directory of the build directory.

Under Linux, the compilation of ConvertGliToVtk may fail due to missing of library on the system (the error message could be: cannot find -lVtkVis)

···

On 04.03.2014 17:24, Wenqing Wang wrote:

These are for fixing the broken tool that can convert the recharge data (in GIS shape syntax, e.g. from mHM) to node-wise sources for the FEM.

Wenqing

Dose anybody mind me to merge my branch https://svn.ufz.de/svn/ogs/branches/Multiphase/new_petsc to the trunk?

Wenqing

Dear Wenqing,

Could you please tell us a summary of what you have changed there?

Best,
Nori

···

On 03/07/2014 10:32 AM, Wenqing Wang wrote:

Dose anybody mind me to merge my branch
https://svn.ufz.de/svn/ogs/branches/Multiphase/new_petsc to the trunk?

Wenqing

--
Dr.-Ing. Norihiro Watanabe
Department of Environmental Informatics (ENVINF)
Wissenschaftler

Helmholtz-Zentrum für Umweltforschung GmbH - UFZ
Helmholtz Centre for Environmental Research GmbH - UFZ
Permoserstraße 15 / 04318 Leipzig / Germany

norihiro.watanabe@ufz.de / http://www.ufz.de
Telefon +49 341 235 1806

Sitz der Gesellschaft: Leipzig
Registergericht: Amtsgericht Leipzig, Handelsregister Nr. B 4703
Vorsitzender des Aufsichtsrats: MinDirig Wilfried Kraus
Wissenschaftlicher Geschäftsführer: Prof. Dr. Georg Teutsch