In order to have better performance on juqueen, I have optimized class Matrix, and removed some other used classes and functions like SymMatrx, ElementMatrix, AllocateLocalMatrixMemory and etc.
With that changes, the analysis of 3D deformation problem, which needs large dimension matrix in the local assembly, could get 8%~15% decrease of the CPU time.
You can view the changes here:
https://svn.ufz.de/ogs/changeset/13017
and the source code is here by the link:
https://svn.ufz.de/svn/ogs/branches/Multiphase/new_petsc
If there is no objection, I will merge the branch to the trunk in next week.
Wenqing
Dear Wenqing,
It looks the new code does not support $MEMORY_TYPE 1 any more. $MEMORY_TYPE 1 means OGS computes local matrices only once at the first time step and reuse them in later time steps. Is it right? If yes, I'd like to know why it matters the performance. Actually $MEMORY_TYPE 1 speedup simulations when coefficients are constant.
Best regards,
Nori
···
On 03/21/2014 05:09 PM, Wenqing Wang wrote:
In order to have better performance on juqueen, I have optimized class
Matrix, and removed some other used classes and functions like SymMatrx,
ElementMatrix, AllocateLocalMatrixMemory and etc.
With that changes, the analysis of 3D deformation problem, which needs
large dimension matrix in the local assembly, could get 8%~15% decrease
of the CPU time.
You can view the changes here:
https://svn.ufz.de/ogs/changeset/13017
and the source code is here by the link:
https://svn.ufz.de/svn/ogs/branches/Multiphase/new_petsc
If there is no objection, I will merge the branch to the trunk in next
week.
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
Administrativer Geschäftsführer: Dr. Heike Graßmann
Dear Nori,
The dropping of $MEMORY_TYPE 1 is not directly related to my current optimization (which mainly focuses in class Matrix). I removed it because the functionality of $MEMORY_TYPE 1 is not used any more and there are many pieces source code related to it. With $MEMORY_TYPE 1, all element matrix and vectors from the local assembly are stored in a long vector to avoid local assembly for the next global assembly. This functionality was induced at the early time of OGS5 in order to realize a steady state simulation or the problem with no much change in the left hand side. It is memory consuming and seems nobody uses it anymore. Besides, the steady state of a process was achieved late on by saving the solution and using the saved solution for other coupled process.
Have a nice weekend.
Wenqing
···
On 21.03.2014 17:26, Norihiro Watanabe wrote:
Dear Wenqing,
It looks the new code does not support $MEMORY_TYPE 1 any more. $MEMORY_TYPE 1 means OGS computes local matrices only once at the first time step and reuse them in later time steps. Is it right? If yes, I'd like to know why it matters the performance. Actually $MEMORY_TYPE 1 speedup simulations when coefficients are constant.
Best regards,
Nori
On 03/21/2014 05:09 PM, Wenqing Wang wrote:
In order to have better performance on juqueen, I have optimized class
Matrix, and removed some other used classes and functions like SymMatrx,
ElementMatrix, AllocateLocalMatrixMemory and etc.
With that changes, the analysis of 3D deformation problem, which needs
large dimension matrix in the local assembly, could get 8%~15% decrease
of the CPU time.
You can view the changes here:
https://svn.ufz.de/ogs/changeset/13017
and the source code is here by the link:
https://svn.ufz.de/svn/ogs/branches/Multiphase/new_petsc
If there is no objection, I will merge the branch to the trunk in next
week.
Wenqing
Dear Wenqing, dear Nori,
$MEMORY_TYPE 1 actually is used a lot in our applications and it would be a big problem for us to lose the option to suppress recalculation of steady state distributions.
> Besides, the steady state of a process was achieved late on by saving
> the solution and using the saved solution for other coupled process.
If there is another way to achieve this could you please give me the details on how to make use of this.
Have a nice weekend,
Christof
···
Am 21.03.2014 17:58, schrieb Wenqing Wang:
Dear Nori,
The dropping of $MEMORY_TYPE 1 is not directly related to my current
optimization (which mainly focuses in class Matrix). I removed it
because the functionality of $MEMORY_TYPE 1 is not used any more and
there are many pieces source code related to it. With $MEMORY_TYPE 1,
all element matrix and vectors from the local assembly are stored in a
long vector to avoid local assembly for the next global assembly. This
functionality was induced at the early time of OGS5 in order to realize
a steady state simulation or the problem with no much change in the
left hand side. It is memory consuming and seems nobody uses it anymore.
Besides, the steady state of a process was achieved late on by saving
the solution and using the saved solution for other coupled process.
Have a nice weekend.
Wenqing
On 21.03.2014 17:26, Norihiro Watanabe wrote:
Dear Wenqing,
It looks the new code does not support $MEMORY_TYPE 1 any more.
$MEMORY_TYPE 1 means OGS computes local matrices only once at the
first time step and reuse them in later time steps. Is it right? If
yes, I'd like to know why it matters the performance. Actually
$MEMORY_TYPE 1 speedup simulations when coefficients are constant.
Best regards,
Nori
On 03/21/2014 05:09 PM, Wenqing Wang wrote:
In order to have better performance on juqueen, I have optimized class
Matrix, and removed some other used classes and functions like SymMatrx,
ElementMatrix, AllocateLocalMatrixMemory and etc.
With that changes, the analysis of 3D deformation problem, which needs
large dimension matrix in the local assembly, could get 8%~15% decrease
of the CPU time.
You can view the changes here:
https://svn.ufz.de/ogs/changeset/13017
and the source code is here by the link:
https://svn.ufz.de/svn/ogs/branches/Multiphase/new_petsc
If there is no objection, I will merge the branch to the trunk in next
week.
Wenqing
--
_______________________________________
Dr. Christof Beyer
Institute of Geosciences
Geohydromodelling
Christian-Albrechts-University Kiel
Ludewig-Meyn-Str. 10
24118 Kiel
Germany
phone: +49(0)431-8803172
fax: +49(0)431-8807606
mobile: +49(0)176-24297908
email: christof.beyer@gpi.uni-kiel.de
home: http://www.ifg.uni-kiel.de/
_______________________________________
Dear Wenqing,
If it is not related to the optimization, I'm opposed to remove $MEMORY_TYPE 1 because I'm using it for transient simulations, e.g. transport modeling with constant velocity, transient groundwater simulations with constant properties. The functionality is useful as it really saves the computation time. They are also used in some of my benchmarks, e.g. NUMERICS/SUPG, NUMERICS/FEM_FCT.
Best regards,
Nori
···
On 03/21/2014 05:58 PM, Wenqing Wang wrote:
Dear Nori,
The dropping of $MEMORY_TYPE 1 is not directly related to my current
optimization (which mainly focuses in class Matrix). I removed it
because the functionality of $MEMORY_TYPE 1 is not used any more and
there are many pieces source code related to it. With $MEMORY_TYPE 1,
all element matrix and vectors from the local assembly are stored in a
long vector to avoid local assembly for the next global assembly. This
functionality was induced at the early time of OGS5 in order to realize
a steady state simulation or the problem with no much change in the
left hand side. It is memory consuming and seems nobody uses it anymore.
Besides, the steady state of a process was achieved late on by saving
the solution and using the saved solution for other coupled process.
Have a nice weekend.
Wenqing
On 21.03.2014 17:26, Norihiro Watanabe wrote:
Dear Wenqing,
It looks the new code does not support $MEMORY_TYPE 1 any more.
$MEMORY_TYPE 1 means OGS computes local matrices only once at the
first time step and reuse them in later time steps. Is it right? If
yes, I'd like to know why it matters the performance. Actually
$MEMORY_TYPE 1 speedup simulations when coefficients are constant.
Best regards,
Nori
On 03/21/2014 05:09 PM, Wenqing Wang wrote:
In order to have better performance on juqueen, I have optimized class
Matrix, and removed some other used classes and functions like SymMatrx,
ElementMatrix, AllocateLocalMatrixMemory and etc.
With that changes, the analysis of 3D deformation problem, which needs
large dimension matrix in the local assembly, could get 8%~15% decrease
of the CPU time.
You can view the changes here:
https://svn.ufz.de/ogs/changeset/13017
and the source code is here by the link:
https://svn.ufz.de/svn/ogs/branches/Multiphase/new_petsc
If there is no objection, I will merge the branch to the trunk in next
week.
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
Administrativer Geschäftsführer: Dr. Heike Graßmann
Dear Nori and Christof,
OK. It will not be touched.
Cheers,
Wenqing
···
On 24.03.2014 10:25, Norihiro Watanabe wrote:
Dear Wenqing,
If it is not related to the optimization, I'm opposed to remove $MEMORY_TYPE 1 because I'm using it for transient simulations, e.g. transport modeling with constant velocity, transient groundwater simulations with constant properties. The functionality is useful as it really saves the computation time. They are also used in some of my benchmarks, e.g. NUMERICS/SUPG, NUMERICS/FEM_FCT.
Best regards,
Nori
On 03/21/2014 05:58 PM, Wenqing Wang wrote:
Dear Nori,
The dropping of $MEMORY_TYPE 1 is not directly related to my current
optimization (which mainly focuses in class Matrix). I removed it
because the functionality of $MEMORY_TYPE 1 is not used any more and
there are many pieces source code related to it. With $MEMORY_TYPE 1,
all element matrix and vectors from the local assembly are stored in a
long vector to avoid local assembly for the next global assembly. This
functionality was induced at the early time of OGS5 in order to realize
a steady state simulation or the problem with no much change in the
left hand side. It is memory consuming and seems nobody uses it anymore.
Besides, the steady state of a process was achieved late on by saving
the solution and using the saved solution for other coupled process.
Have a nice weekend.
Wenqing
On 21.03.2014 17:26, Norihiro Watanabe wrote:
Dear Wenqing,
It looks the new code does not support $MEMORY_TYPE 1 any more.
$MEMORY_TYPE 1 means OGS computes local matrices only once at the
first time step and reuse them in later time steps. Is it right? If
yes, I'd like to know why it matters the performance. Actually
$MEMORY_TYPE 1 speedup simulations when coefficients are constant.
Best regards,
Nori
On 03/21/2014 05:09 PM, Wenqing Wang wrote:
In order to have better performance on juqueen, I have optimized class
Matrix, and removed some other used classes and functions like SymMatrx,
ElementMatrix, AllocateLocalMatrixMemory and etc.
With that changes, the analysis of 3D deformation problem, which needs
large dimension matrix in the local assembly, could get 8%~15% decrease
of the CPU time.
You can view the changes here:
https://svn.ufz.de/ogs/changeset/13017
and the source code is here by the link:
https://svn.ufz.de/svn/ogs/branches/Multiphase/new_petsc
If there is no objection, I will merge the branch to the trunk in next
week.
Wenqing
Dear All,
Now a new branch without touching $MEMORY_TYPE stuffs.
https://svn.ufz.de/ogs/changeset/13034
Best,
Wenqing
···
On 24.03.2014 10:25, Norihiro Watanabe wrote:
Dear Wenqing,
If it is not related to the optimization, I'm opposed to remove $MEMORY_TYPE 1 because I'm using it for transient simulations, e.g. transport modeling with constant velocity, transient groundwater simulations with constant properties. The functionality is useful as it really saves the computation time. They are also used in some of my benchmarks, e.g. NUMERICS/SUPG, NUMERICS/FEM_FCT.
Best regards,
Nori
On 03/21/2014 05:58 PM, Wenqing Wang wrote:
Dear Nori,
The dropping of $MEMORY_TYPE 1 is not directly related to my current
optimization (which mainly focuses in class Matrix). I removed it
because the functionality of $MEMORY_TYPE 1 is not used any more and
there are many pieces source code related to it. With $MEMORY_TYPE 1,
all element matrix and vectors from the local assembly are stored in a
long vector to avoid local assembly for the next global assembly. This
functionality was induced at the early time of OGS5 in order to realize
a steady state simulation or the problem with no much change in the
left hand side. It is memory consuming and seems nobody uses it anymore.
Besides, the steady state of a process was achieved late on by saving
the solution and using the saved solution for other coupled process.
Have a nice weekend.
Wenqing
On 21.03.2014 17:26, Norihiro Watanabe wrote:
Dear Wenqing,
It looks the new code does not support $MEMORY_TYPE 1 any more.
$MEMORY_TYPE 1 means OGS computes local matrices only once at the
first time step and reuse them in later time steps. Is it right? If
yes, I'd like to know why it matters the performance. Actually
$MEMORY_TYPE 1 speedup simulations when coefficients are constant.
Best regards,
Nori
On 03/21/2014 05:09 PM, Wenqing Wang wrote:
In order to have better performance on juqueen, I have optimized class
Matrix, and removed some other used classes and functions like SymMatrx,
ElementMatrix, AllocateLocalMatrixMemory and etc.
With that changes, the analysis of 3D deformation problem, which needs
large dimension matrix in the local assembly, could get 8%~15% decrease
of the CPU time.
You can view the changes here:
https://svn.ufz.de/ogs/changeset/13017
and the source code is here by the link:
https://svn.ufz.de/svn/ogs/branches/Multiphase/new_petsc
If there is no objection, I will merge the branch to the trunk in next
week.
Wenqing
Thank you, Wenqing. please also update the version number.
Best,
Nori
···
On 03/26/2014 12:02 PM, Wenqing Wang wrote:
Dear All,
Now a new branch without touching $MEMORY_TYPE stuffs.
https://svn.ufz.de/ogs/changeset/13034
Best,
Wenqing
On 24.03.2014 10:25, Norihiro Watanabe wrote:
Dear Wenqing,
If it is not related to the optimization, I'm opposed to remove
$MEMORY_TYPE 1 because I'm using it for transient simulations, e.g.
transport modeling with constant velocity, transient groundwater
simulations with constant properties. The functionality is useful as
it really saves the computation time. They are also used in some of my
benchmarks, e.g. NUMERICS/SUPG, NUMERICS/FEM_FCT.
Best regards,
Nori
On 03/21/2014 05:58 PM, Wenqing Wang wrote:
Dear Nori,
The dropping of $MEMORY_TYPE 1 is not directly related to my current
optimization (which mainly focuses in class Matrix). I removed it
because the functionality of $MEMORY_TYPE 1 is not used any more and
there are many pieces source code related to it. With $MEMORY_TYPE 1,
all element matrix and vectors from the local assembly are stored in a
long vector to avoid local assembly for the next global assembly. This
functionality was induced at the early time of OGS5 in order to realize
a steady state simulation or the problem with no much change in the
left hand side. It is memory consuming and seems nobody uses it anymore.
Besides, the steady state of a process was achieved late on by saving
the solution and using the saved solution for other coupled process.
Have a nice weekend.
Wenqing
On 21.03.2014 17:26, Norihiro Watanabe wrote:
Dear Wenqing,
It looks the new code does not support $MEMORY_TYPE 1 any more.
$MEMORY_TYPE 1 means OGS computes local matrices only once at the
first time step and reuse them in later time steps. Is it right? If
yes, I'd like to know why it matters the performance. Actually
$MEMORY_TYPE 1 speedup simulations when coefficients are constant.
Best regards,
Nori
On 03/21/2014 05:09 PM, Wenqing Wang wrote:
In order to have better performance on juqueen, I have optimized class
Matrix, and removed some other used classes and functions like
SymMatrx,
ElementMatrix, AllocateLocalMatrixMemory and etc.
With that changes, the analysis of 3D deformation problem, which needs
large dimension matrix in the local assembly, could get 8%~15%
decrease
of the CPU time.
You can view the changes here:
https://svn.ufz.de/ogs/changeset/13017
and the source code is here by the link:
https://svn.ufz.de/svn/ogs/branches/Multiphase/new_petsc
If there is no objection, I will merge the branch to the trunk in
next
week.
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
Administrativer Geschäftsführer: Dr. Heike Graßmann
In addition to previous changes, PETSc for PS_GLOBAL model has been added. You can find the changes in the attached file or by visiting our private github page:
https://github.com/envinf/ogs5_ww
(Click button'Compare & pull request' for branch opr_m_pls_parPS)
where branch pr_dev is for branch develop of the og5_trunk, and it is ready to be merged.
Best,
Wenqing
diff.pdf (138 KB)
···
On 21.03.2014 17:09, Wenqing Wang wrote:
In order to have better performance on juqueen, I have optimized class Matrix, and removed some other used classes and functions like SymMatrx, ElementMatrix, AllocateLocalMatrixMemory and etc.
With that changes, the analysis of 3D deformation problem, which needs large dimension matrix in the local assembly, could get 8%~15% decrease of the CPU time.
You can view the changes here:
https://svn.ufz.de/ogs/changeset/13017
and the source code is here by the link:
https://svn.ufz.de/svn/ogs/branches/Multiphase/new_petsc
If there is no objection, I will merge the branch to the trunk in next week.
Wenqing