Closed asartori86 closed 5 years ago
I tried several strategies to speed up find_matrix_K_3D
without success. @yakopuz, there is the variable cnt
which is updated several times during an iteration of the for loop. It is not clear to me if at beginning of each iteration cnt = C * i
, i.e. cnt
is incremented by the same amount per iteration. If so, we may parallelize also this function quite straightforwardly
@yakopuz @ecor @cozzini @ElisaBortoli, I see that the cnt
variable is basically updated 3 times
per iteration, but sometimes just 2. Do you know why? can we predict for which iteration the previous one updated cnt
just twice instead of three times?
I am talking about the find_matrix_K_3D
function
@yakopuz @ecor @cozzini @ElisaBortoli, I see that the
cnt
variable is basically updated3 times
per iteration, but sometimes just 2. Do you know why? can we predict for which iteration the previous one updatedcnt
just twice instead of three times?
@asartori86 This is apart that I know little ... I see only:
/* cnt is the counter of Li Lp Lx (lower diagonal without diagonal) /
I see that for different situations (vertical flow, surface flow, and so on) there are loops in count. @ecor do you understand better how find_matrix_K_3D works?
thanks @yakopuz, and do you know if EnergyBalance
and WaterBalance
could be overlapped? or they modify the same variables and they have to run sequentially?
/* cnt is the counter of Li Lp Lx (lower diagonal without diagonal) /
I don't know what Li
, Lp
, and Lx
are but only Lx
are written inside the function
cnt++;
(*Lx)[cnt] = ... ;
Alberto,
The physics should work in this way: The model solves before the energy balance, then the water balance.
However, there is some coupling among the two. When you solve the energy balance you calculate the evapotranspiration on the basis of the available water, so you need to subtract this water from the water balance. The functions that are doing this are update_soil_land and update_soil_channel in energy.balance.cc. If the mass budget calculation is not satisfied, this could trigger some recalculation of energy balance and water balance.
I do not know the exact details of the implementation, however I would start to look on time_loop in geotop.cc. I would look how time stepping is implemented. From a quick look, I understand that, after some initializations, at line 311 you run first the energy balance, then if this has success en == 0 you run the water balance, any of them do not have success line 329 if (en != 0 || wt != 0), then you try to calculate them again with a shorter time steps. Notice that you can have different error values for en and wt, depending on what happens.
To better understand the code I would recommend (at least it would be very helpful also for me to better assist you and Elisa):
Giacomo
From: Alberto Sartori notifications@github.com Sent: Tuesday, 27 November, 2018 09:18 To: geotopmodel/geotop geotop@noreply.github.com Cc: Bertoldi Giacomo giacomo.bertoldi@eurac.edu; Mention mention@noreply.github.com Subject: Re: [geotopmodel/geotop] A bit of optimization for Richards3D (#96)
thanks @yakopuzhttps://github.com/yakopuz, and do you know if EnergyBalance and WaterBalance could be overlapped? or they modify the same variables and they have to run sequentially? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/geotopmodel/geotop/pull/96, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AP8hXFHWw50dDicTPKelQcEl_7Lo-7vXks5uzPVCgaJpZM4YxlMD.[https://github.com/notifications/beacon/AP8hXA9lP_4Xr0Is-7QEpgpf1aOCv66iks5uzPVCgaJpZM4YxlMD.gif]
/* cnt is the counter of Li Lp Lx (lower diagonal without diagonal) /
I don't know what
Li
,Lp
, andLx
are but onlyLx
are written inside the functioncnt++; (*Lx)[cnt] = ... ;
I see are defined in indices.cc as in void cont_nonzero_values_matrix3. They seems to be the indices of the cells to which another cell is communicating, the cell below or above or next to the calculation cell. Depending on the process, they could be different. I suppose for example for surface flow the next cell below, but for subsurface flow the the two next cell and so on ... If you are on the border, you mighth have less cells communicating ....
Understanding this topology could be very important for a effort of parallelization MPI - style.
Hi @yakopuz https://github.com/yakopuz @ecor https://github.com/ecor @cozzini https://github.com/cozzini @ElisaBortoli https://github.com/ElisaBortoli, @asartori86 https://github.com/asartori86 . find_K_3D_matrix looks to calculate a term, the Lx pointer (the 4th pointer) , which is function of hydraulic conductivity and is part of the matrix that is solved in the core ODE system within the Newton-like iterator.
Each term of this quantity Lx is refererred to each cell of the Richards3D integration domain, cnt is a counter .
In fact, it is called in case of update=TRUE. So I can see from the code.
cheers Emanuele
Il giorno lun 26 nov 2018 alle ore 18:07 Giacomo Bertoldi < notifications@github.com> ha scritto:
@yakopuz https://github.com/yakopuz @ecor https://github.com/ecor @cozzini https://github.com/cozzini @ElisaBortoli https://github.com/ElisaBortoli, I see that the cnt variable is basically updated 3 times per iteration, but sometimes just 2. Do you know why? can we predict for which iteration the previous one updated cnt just twice instead of three times?
@asartori86 https://github.com/asartori86 This is apart that I know little ... I see only:
/* cnt is the counter of Li Lp Lx (lower diagonal without diagonal) /
I see that for different situations (vertical flow, surface flow, and so on) there are loops in count. @ecor https://github.com/ecor do you understand better how find_matrix_K_3D works?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/geotopmodel/geotop/pull/96#issuecomment-441718275, or mute the thread https://github.com/notifications/unsubscribe-auth/AEQ3gSY3Eg8Yk1-cmbPXeWuNMmKQkqxIks5uzB_rgaJpZM4YxlMD .
-- Emanuele Cordano, PhD Environmental Engineer / Ingegnere per l' Ambiente e il territorio nr. 3587 (Albo A - Provincia di Trento) cell: +39 3282818564 email: emanuele.cordano@gmail.com,emanuele.cordano@rendena100.eu, emanuele.cordano@eurac.edu PEC: emanuele.cordano@ingpec.eu URL: www.rendena100.eu LinkedIn: https://www.linkedin.com/in/emanuele-cordano-31995333 GitHub: https://github.com/ecor
The Lx term might be referenced to each border between two cells. So the counter is defined per each border between 2 cells . You should check but it makes sense. I remember when I wrote a per for a 2D similar problem , it looks like the tensor T in https://agupubs.onlinelibrary.wiley.com/doi/full/10.1002/wrcr.20072 , see tensor T eq 20 ans 21. In GEOtop it is more complicated (it is 3D) but this is similar. cheers @ecor
Il giorno mar 27 nov 2018 alle ore 23:19 Emanuele Cordano < emanuele.cordano@gmail.com> ha scritto:
Hi @yakopuz https://github.com/yakopuz @ecor https://github.com/ecor @cozzini https://github.com/cozzini @ElisaBortoli https://github.com/ElisaBortoli, @asartori86 https://github.com/asartori86 . find_K_3D_matrix looks to calculate a term, the Lx pointer (the 4th pointer) , which is function of hydraulic conductivity and is part of the matrix that is solved in the core ODE system within the Newton-like iterator.
Each term of this quantity Lx is refererred to each cell of the Richards3D integration domain, cnt is a counter .
In fact, it is called in case of update=TRUE. So I can see from the code.
cheers Emanuele
Il giorno lun 26 nov 2018 alle ore 18:07 Giacomo Bertoldi < notifications@github.com> ha scritto:
@yakopuz https://github.com/yakopuz @ecor https://github.com/ecor @cozzini https://github.com/cozzini @ElisaBortoli https://github.com/ElisaBortoli, I see that the cnt variable is basically updated 3 times per iteration, but sometimes just 2. Do you know why? can we predict for which iteration the previous one updated cnt just twice instead of three times?
@asartori86 https://github.com/asartori86 This is apart that I know little ... I see only:
/* cnt is the counter of Li Lp Lx (lower diagonal without diagonal) /
I see that for different situations (vertical flow, surface flow, and so on) there are loops in count. @ecor https://github.com/ecor do you understand better how find_matrix_K_3D works?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/geotopmodel/geotop/pull/96#issuecomment-441718275, or mute the thread https://github.com/notifications/unsubscribe-auth/AEQ3gSY3Eg8Yk1-cmbPXeWuNMmKQkqxIks5uzB_rgaJpZM4YxlMD .
-- Emanuele Cordano, PhD Environmental Engineer / Ingegnere per l' Ambiente e il territorio nr. 3587 (Albo A - Provincia di Trento) cell: +39 3282818564 email: emanuele.cordano@gmail.com,emanuele.cordano@rendena100.eu, emanuele.cordano@eurac.edu PEC: emanuele.cordano@ingpec.eu URL: www.rendena100.eu LinkedIn: https://www.linkedin.com/in/emanuele-cordano-31995333 GitHub: https://github.com/ecor
-- Emanuele Cordano, PhD Environmental Engineer / Ingegnere per l' Ambiente e il territorio nr. 3587 (Albo A - Provincia di Trento) cell: +39 3282818564 email: emanuele.cordano@gmail.com,emanuele.cordano@rendena100.eu, emanuele.cordano@eurac.edu PEC: emanuele.cordano@ingpec.eu URL: www.rendena100.eu LinkedIn: https://www.linkedin.com/in/emanuele-cordano-31995333 GitHub: https://github.com/ecor
I started to work on
Richards3D
and I added several scoped timers to the functions called insideRichards3D
. The currentv3.0
(configured with-DMATH_OPTIM=true
on my laptop produce this output when the thest Muntatschini_ref_005 is runAs you can see, the two most expensive functions called by
Richards3D
arefind_matrix_K_3D
andfind_f_3D
. The latter is well suited for a parallelization through openMP. After adding the pragma, and configuring with-DWITH_OMP=true
, the output is the following (lookfind_f_3D
)lookin at the functions that are called I realized that many functions that were written in a
.cc
file should be declaredinline
inside an header since they are pretty small. With the inlining we gained few percent.