<div dir="ltr">Thanks a lot. If you need more information and/or my code again, please let me know.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em sex., 1 de abr. de 2022 às 19:27, Barry Smith <<a href="mailto:bsmith@petsc.dev">bsmith@petsc.dev</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><br></div> I'll take a look at it this weekend. The computed preconditioned residual norm is a real number so I am not sure where PETSc will be able to detect the problem appropriately before it is too late.<div><br><div><br><blockquote type="cite"><div>On Apr 1, 2022, at 6:14 PM, Giovane Avancini <<a href="mailto:giavancini@usp.br" target="_blank">giavancini@usp.br</a>> wrote:</div><br><div><div dir="ltr">Hi Barry, it's me again.<div><br></div><div>Sorry to bother you with this issue, but the problem is still happening, now when using KSPIBCGS. As you can see below, even when a NaN pops up in the residual, the solver still converges to an INF solution.</div><div><br></div><div>----------------------- TIME STEP = 3318, time = 0.663600 -----------------------<br><br>Mesh Regenerated. Elapsed time: 0.018536<br>Isolated nodes: 14<br>Assemble Linear System. Elapsed time: 0.030077<br> 0 KSP preconditioned resid norm 4.087133454416e+04 true resid norm -nan ||r(i)||/||b|| -nan<br> 1 KSP preconditioned resid norm 8.670288259109e+03 true resid norm -nan ||r(i)||/||b|| -nan<br> 2 KSP preconditioned resid norm 4.875596419197e+03 true resid norm -nan ||r(i)||/||b|| -nan<br> 3 KSP preconditioned resid norm 1.226640070761e+03 true resid norm -nan ||r(i)||/||b|| -nan<br> 4 KSP preconditioned resid norm 7.121904546851e+02 true resid norm -nan ||r(i)||/||b|| -nan<br> 5 KSP preconditioned resid norm 5.990560906831e+02 true resid norm -nan ||r(i)||/||b|| -nan<br> 6 KSP preconditioned resid norm 4.256157374933e+02 true resid norm -nan ||r(i)||/||b|| -nan<br> 7 KSP preconditioned resid norm 3.274351035311e+02 true resid norm -nan ||r(i)||/||b|| -nan<br> 8 KSP preconditioned resid norm 2.436138522439e+02 true resid norm -nan ||r(i)||/||b|| -nan<br> 9 KSP preconditioned resid norm 1.268089193578e+02 true resid norm -nan ||r(i)||/||b|| -nan<br> 10 KSP preconditioned resid norm 1.093950736015e+02 true resid norm -nan ||r(i)||/||b|| -nan<br> 11 KSP preconditioned resid norm 9.950531836062e+01 true resid norm -nan ||r(i)||/||b|| -nan<br> 12 KSP preconditioned resid norm 1.066841140901e+02 true resid norm -nan ||r(i)||/||b|| -nan<br> 13 KSP preconditioned resid norm 1.003475554456e+02 true resid norm -nan ||r(i)||/||b|| -nan<br> 14 KSP preconditioned resid norm 1.073513486989e+02 true resid norm -nan ||r(i)||/||b|| -nan<br> 15 KSP preconditioned resid norm 8.724609972930e+01 true resid norm -nan ||r(i)||/||b|| -nan<br> 16 KSP preconditioned resid norm 1.445166180332e+02 true resid norm -nan ||r(i)||/||b|| -nan<br> 17 KSP preconditioned resid norm 3.767376396291e+01 true resid norm -nan ||r(i)||/||b|| -nan<br> 18 KSP preconditioned resid norm 7.597770355737e+01 true resid norm -nan ||r(i)||/||b|| -nan<br> 19 KSP preconditioned resid norm 3.208030402538e+01 true resid norm -nan ||r(i)||/||b|| -nan<br> 20 KSP preconditioned resid norm 3.477715841173e+01 true resid norm -nan ||r(i)||/||b|| -nan<br> 21 KSP preconditioned resid norm 2.880337856055e+01 true resid norm -nan ||r(i)||/||b|| -nan<br> 22 KSP preconditioned resid norm 2.730108581171e+01 true resid norm -nan ||r(i)||/||b|| -nan<br> 23 KSP preconditioned resid norm 2.111131168298e+01 true resid norm -nan ||r(i)||/||b|| -nan<br> 24 KSP preconditioned resid norm 1.635560497545e+01 true resid norm -nan ||r(i)||/||b|| -nan<br> 25 KSP preconditioned resid norm 1.550914551701e+01 true resid norm -nan ||r(i)||/||b|| -nan<br> 26 KSP preconditioned resid norm 1.409066040669e+01 true resid norm -nan ||r(i)||/||b|| -nan<br> 27 KSP preconditioned resid norm 1.032086999081e+01 true resid norm -nan ||r(i)||/||b|| -nan<br> 28 KSP preconditioned resid norm 1.111168488798e+01 true resid norm -nan ||r(i)||/||b|| -nan<br> 29 KSP preconditioned resid norm 9.898696915473e+00 true resid norm -nan ||r(i)||/||b|| -nan<br> 30 KSP preconditioned resid norm 1.234283818664e+01 true resid norm -nan ||r(i)||/||b|| -nan<br> 31 KSP preconditioned resid norm 2.735222111838e+01 true resid norm -nan ||r(i)||/||b|| -nan<br> 32 KSP preconditioned resid norm 6.431272223321e+00 true resid norm -nan ||r(i)||/||b|| -nan<br> 33 KSP preconditioned resid norm 6.320133000091e+00 true resid norm -nan ||r(i)||/||b|| -nan<br> 34 KSP preconditioned resid norm 6.568217058049e+00 true resid norm -nan ||r(i)||/||b|| -nan<br> 35 KSP preconditioned resid norm 6.483075335206e+00 true resid norm -nan ||r(i)||/||b|| -nan<br> 36 KSP preconditioned resid norm 6.419074566626e+00 true resid norm -nan ||r(i)||/||b|| -nan<br> 37 KSP preconditioned resid norm 6.372749647101e+00 true resid norm -nan ||r(i)||/||b|| -nan<br> 38 KSP preconditioned resid norm 5.920214853455e+00 true resid norm -nan ||r(i)||/||b|| -nan<br> 39 KSP preconditioned resid norm 5.953698988377e+00 true resid norm -nan ||r(i)||/||b|| -nan<br> 40 KSP preconditioned resid norm 4.009279521077e+00 true resid norm -nan ||r(i)||/||b|| -nan<br> 41 KSP preconditioned resid norm 8.407438130288e+00 true resid norm -nan ||r(i)||/||b|| -nan<br> 42 KSP preconditioned resid norm 1.924008529878e+00 true resid norm -nan ||r(i)||/||b|| -nan<br> 43 KSP preconditioned resid norm 9.126618449455e+00 true resid norm -nan ||r(i)||/||b|| -nan<br> 44 KSP preconditioned resid norm 2.747853629308e+00 true resid norm -nan ||r(i)||/||b|| -nan<br> 45 KSP preconditioned resid norm 2.556706051040e+00 true resid norm -nan ||r(i)||/||b|| -nan<br> 46 KSP preconditioned resid norm 2.427212844835e+00 true resid norm -nan ||r(i)||/||b|| -nan<br> 47 KSP preconditioned resid norm 7.630151877379e+00 true resid norm -nan ||r(i)||/||b|| -nan<br> 48 KSP preconditioned resid norm 5.895961768741e-01 true resid norm -nan ||r(i)||/||b|| -nan<br> 49 KSP preconditioned resid norm 2.271378954392e-01 true resid norm -nan ||r(i)||/||b|| -nan<br> 50 KSP preconditioned resid norm 1.779670755839e-01 true resid norm -nan ||r(i)||/||b|| -nan<br> 51 KSP preconditioned resid norm 1.488459722777e-01 true resid norm -nan ||r(i)||/||b|| -nan<br> 52 KSP preconditioned resid norm 1.479802491212e-01 true resid norm -nan ||r(i)||/||b|| -nan<br> 53 KSP preconditioned resid norm 1.316523287251e-01 true resid norm -nan ||r(i)||/||b|| -nan<br> 54 KSP preconditioned resid norm 1.347849424457e-01 true resid norm -nan ||r(i)||/||b|| -nan<br> 55 KSP preconditioned resid norm 6.739405576032e-02 true resid norm -nan ||r(i)||/||b|| -nan<br> 56 KSP preconditioned resid norm 6.699633313335e-02 true resid norm -nan ||r(i)||/||b|| -nan<br> 57 KSP preconditioned resid norm 8.064741830609e-02 true resid norm -nan ||r(i)||/||b|| -nan<br> 58 KSP preconditioned resid norm 6.744985187452e-02 true resid norm -nan ||r(i)||/||b|| -nan<br> 59 KSP preconditioned resid norm 6.981071339163e-02 true resid norm -nan ||r(i)||/||b|| -nan<br> 60 KSP preconditioned resid norm 4.410819986572e-02 true resid norm -nan ||r(i)||/||b|| -nan<br> 61 KSP preconditioned resid norm 4.062281042354e-02 true resid norm -nan ||r(i)||/||b|| -nan<br>Linear solve converged due to CONVERGED_RTOL iterations 61<br>Solver converged within 61 iterations. Elapsed time: 0.117009<br>Newton iteration: 0 - L2 Position Norm: INF - L2 Pressure Norm: INF<br>Memory used by each processor: 47.843750 Mb<br></div><div><br></div><div>Could you please check if the issue can be fixed the same way as you did for the GMRES family solvers? Thanks in advance,</div><div><br></div><div>Kind regards,</div><div><br></div><div>Giovane</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em ter., 8 de mar. de 2022 às 01:05, Barry Smith <<a href="mailto:bsmith@petsc.dev" target="_blank">bsmith@petsc.dev</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><br></div> I ran with -info and get repeated <div><br></div><div><div style="margin:0px;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">MatPivotCheck_none(): Detected zero pivot in factorization in row 2547 value 0. tolerance 2.22045e-14</span></div><div style="margin:0px;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><br></span></div><div style="margin:0px;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">after the first linear solve failure. The values are always slightly different. My conclusion is that from this point on the default factorization is truly failing each time which is why it is always switching the linear solver. </span></div><div style="margin:0px;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><br></span></div><div style="margin:0px;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"> Barry</span></div><div style="margin:0px;font-stretch:normal;font-size:14px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><br></span></div><div><br><blockquote type="cite"><div>On Mar 7, 2022, at 7:01 PM, Giovane Avancini <<a href="mailto:giavancini@usp.br" target="_blank">giavancini@usp.br</a>> wrote:</div><br><div><div dir="ltr">Sorry, I forgot to attach the file.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em seg., 7 de mar. de 2022 às 21:01, Giovane Avancini <<a href="mailto:giavancini@usp.br" target="_blank">giavancini@usp.br</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks Barry! I included the piece of code you sent and now it seems to be working pretty well. It has completed all the 5000 time steps and the solver is indeed triggering the failure when a NaN/Inf is found.<div><br><div>I just noticed a strange behaviour in my code after the patch that was not happening before, so I was wondering if it could be related to the way you fixed the bug or if it is a coincidence, please find attached the log file.</div><div><br></div><div>At time step 913, the first failure occurs,and it doesn't print the norms of iteration 0 for instance (before, even when the pc ended up failing during the first ksp iteration, the norms were plotted indicating the NaN). Ok, maybe now it verifies that a NaN appeared before the norms are actually computed.</div><div><br></div><div>What is strange to me is that, after the first failure, all the remaining calls to FGMRES have failed as well, which is unlikely to be the case in my view. Would it be possible that some error flags of FGMRES are not being reseted from one call to another? So after the first iteration of step 913, FGMRES is being called with an error flag already set to true?</div></div><div><br></div><div>Anyway, I really appreciate your efforts in finding the bug and trying to help me, thank you very much!</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em seg., 7 de mar. de 2022 às 18:08, Barry Smith <<a href="mailto:bsmith@petsc.dev" target="_blank">bsmith@petsc.dev</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><br></div> The fix for the problem Geiovane encountered is in <a href="https://gitlab.com/petsc/petsc/-/merge_requests/4934" target="_blank">https://gitlab.com/petsc/petsc/-/merge_requests/4934</a><div><br><div><br><blockquote type="cite"><div>On Mar 3, 2022, at 11:24 AM, Giovane Avancini <<a href="mailto:giavancini@usp.br" target="_blank">giavancini@usp.br</a>> wrote:</div><br><div><div dir="ltr">Sorry for my late reply Barry,<div><br></div><div>Sure I can share the code with you, but unfortunately I don't know how to make docker images. If you don't mind, you can clone the code from github through this link: <a href="mailto:git@github.com" target="_blank">git@github.com</a>:giavancini/runPFEM.git</div><div>It can be easily compiled with cmake, and you can see the dependencies in README.md. Please let me know if you need any other information.</div><div><br></div><div>Kind regards,</div><div><br></div><div>Giovane</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em sex., 25 de fev. de 2022 às 18:22, Barry Smith <<a href="mailto:bsmith@petsc.dev" target="_blank">bsmith@petsc.dev</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><br></div> Hmm, this is going to be tricky to debug why it the Inf/Nan is not found when it should be. <div><br></div><div> In a debugger you can catch/trap floating point exceptions (how to do this depends on your debugger) and then step through the code after that to see why PETSc KSP is not properly noting the Inf/Nan and returning. This may be cumbersome to do if you don't know PETSc well. Is your code easy to build, would be willing to share it to me so I can run it and debug directly? If you know how to make docker images or something you might be able to give it to me easily.</div><div><br></div><div> Barry</div><div><br></div><div><div><br><blockquote type="cite"><div>On Feb 25, 2022, at 3:59 PM, Giovane Avancini <<a href="mailto:giavancini@usp.br" target="_blank">giavancini@usp.br</a>> wrote:</div><br><div><div dir="ltr">Mark, Matthew and Barry,<div><br></div><div>Thank you all for the quick responses.</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><font color="#351c75">Others might have a better idea, but you could run with '-info :ksp' and see if you see any messages like "Linear solver has created a not a number (NaN) as the residual norm, declaring divergence \n"</font></div></div><div><div><font color="#351c75">You could also run with -log_trace and see if it is using KSPConvergedDefault. I'm not sure if this is the method used given your parameters, but I think it is.</font></div></div></blockquote><div>Mark, I ran with both options. I didn't get any messages like "linear solver has created a not a number..." when using -info: ksp. When turning on -log_trace, I could verify that it is using KSPConvergedDefault but what does it mean exactly? When FGMRES converges with the true residual being NaN, I get the following message: [0] KSPConvergedDefault(): Linear solver has converged. Residual norm 8.897908325511e-05 is less than relative tolerance 1.000000000000e-08 times initial right hand side norm 1.466597558465e+04 at iteration 53. No information about NaN whatsoever.</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><font color="#351c75">We check for NaN or Inf, for example, in KSPCheckDot(). if you have the KSP set to error (<a href="https://petsc.org/main/docs/manualpages/KSP/KSPSetErrorIfNotConverged.html" target="_blank">https://petsc.org/main/docs/manualpages/KSP/KSPSetErrorIfNotConverged.html</a>)</font></div></div><div><div><font color="#351c75">then we throw an error, but the return codes do not seem to be checked in your implementation. If not, then we set the flag for divergence.</font></div></div></blockquote><div>Matthew, I do not check the return code in this case because I don't want PETSc to stop if an error occurs during the solving step. I just want to know that it didn't converge and treat this error inside my code. The problem is that the flag for divergence is not always being set when FGMRES is not converging. I was just wondering why it was set during time step 921 and why not for time step 922 as well.</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><font color="#351c75">Thanks for the complete report. It looks like we may be missing a check in our FGMRES implementation that allows the iteration to continue after a NaN/Inf. </font></div></div><div><div><font color="#351c75"><br></font></div></div><div><div><font color="#351c75"> I will explain how we handle the checking and then attach a patch that you can apply to see if it resolves the problem. Whenever our KSP solvers compute a norm we</font></div></div><div><div><font color="#351c75">check after that calculation to verify that the norm is not an Inf or Nan. This is an inexpensive global check across all MPI ranks because immediately after the norm computation all ranks that share the KSP have the same value. If the norm is a Inf or Nan we "short-circuit" the KSP solve and return immediately with an appropriate not converged code. A quick eye-ball inspection of the FGMRES code found a missing check. </font></div></div><div><div><font color="#351c75"><br></font></div></div><div><div><font color="#351c75"> You can apply the attached patch file in the PETSC_DIR with </font></div></div><div><div><font color="#351c75"><br></font></div></div><div><div><font color="#351c75">patch -p1 < fgmres.patch</font></div></div><div><div><font color="#351c75">make libs</font></div></div><div><div><font color="#351c75"><br></font></div></div><div><div><font color="#351c75">then rerun your code and see if it now handles the Inf/NaN correctly. If so we'll patch our release branch with the fix.</font></div></div></blockquote><div>Thank you for checking this, Barry. I applied the patch exactly the way you instructed, however, the problem is still happening. Is there a way to check if the patch was in fact applied? You can see in the attached screenshot the terminal information.</div><div><br></div><div>Kind regards,</div><div><br></div><div>Giovane</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em sex., 25 de fev. de 2022 às 13:48, Barry Smith <<a href="mailto:bsmith@petsc.dev" target="_blank">bsmith@petsc.dev</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><br></div><div> Giovane,</div><div><br></div><div> Thanks for the complete report. It looks like we may be missing a check in our FGMRES implementation that allows the iteration to continue after a NaN/Inf. </div><div><br></div><div> I will explain how we handle the checking and then attach a patch that you can apply to see if it resolves the problem. Whenever our KSP solvers compute a norm we</div><div>check after that calculation to verify that the norm is not an Inf or Nan. This is an inexpensive global check across all MPI ranks because immediately after the norm computation all ranks that share the KSP have the same value. If the norm is a Inf or Nan we "short-circuit" the KSP solve and return immediately with an appropriate not converged code. A quick eye-ball inspection of the FGMRES code found a missing check. </div><div><br></div><div> You can apply the attached patch file in the PETSC_DIR with </div><div><br></div><div>patch -p1 < fgmres.patch</div><div>make libs</div><div><br></div><div>then rerun your code and see if it now handles the Inf/NaN correctly. If so we'll patch our release branch with the fix.</div></div><div><div></div><div><br></div><div> Barry</div><div><br></div><div><br></div><div><br><blockquote type="cite"><div dir="ltr"><div>Giovane</div></div></blockquote></div> <br><div><br><blockquote type="cite"><div>On Feb 25, 2022, at 11:06 AM, Giovane Avancini via petsc-users <<a href="mailto:petsc-users@mcs.anl.gov" target="_blank">petsc-users@mcs.anl.gov</a>> wrote:</div><br><div><div dir="ltr">Dear PETSc users,<div><br></div><div>I'm working on an inhouse code that solves the Navier-Stokes equation in a Lagrangian fashion for free surface flows. Because of the large distortions and pressure gradients, it is quite common to encounter some issues with iterative solvers for some time steps, and because of that, I implemented a function that changes the solver type based on the flag KSPConvergedReason. If this flag is negative after a call to KSPSolve, I solve the same linear system again using a direct method.</div><div><br></div><div>The problem is that, sometimes, KSP keeps converging even though the residual is NaN, and because of that, I'm not able to identify the problem and change the solver, which leads to a solution vector equals to INF and obviously the code ends up crashing. Is it normal to observe this kind of behaviour?</div><div><br></div><div>Please find attached the log produced with the options -ksp_monitor_lg_residualnorm -ksp_log -ksp_view -ksp_monitor_true_residual -ksp_converged_reason and the function that changes the solver. I'm currently using FGMRES and BJACOBI preconditioner with LU for each block. The problem still happens with ILU for example. We can see in the log file that for the time step 921, the true residual is NaN and within just one iteration, the solver fails and it gives the reason DIVERGED_PC_FAILED. I simply changed the solver to MUMPS and it converged for that time step. However, when solving time step 922 we can see that FGMRES converges while the true residual is NaN. Why is that possible? I would appreciate it if someone could clarify this issue to me.</div><div><br></div><div>Kind regards,</div><div>Giovane</div><div><br></div><div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><font size="1" face="tahoma, sans-serif">Giovane Avancini</font><div><font size="1" face="tahoma, sans-serif">Doutorando em Engenharia de Estruturas - Escola de Engenharia de São Carlos, USP</font></div><div><font size="1" face="tahoma, sans-serif"><br></font></div><div><font size="1" face="tahoma, sans-serif">PhD researcher in Structural Engineering - School of Engineering of São Carlos. USP</font></div></div></div></div></div></div></div>
<span id="gmail-m_8395500376552529656gmail-m_-7764169804948922721gmail-m_8734375473004278970gmail-m_-5704634044864832034gmail-m_7227961845865744941gmail-m_-597234831199625208gmail-m_7337395877569710517gmail-m_6259310096911551287gmail-m_1094472000501772005gmail-m_3468206820950415506gmail-m_-7933021170587843311cid:f_l02lsct61"><function.txt></span><span id="gmail-m_8395500376552529656gmail-m_-7764169804948922721gmail-m_8734375473004278970gmail-m_-5704634044864832034gmail-m_7227961845865744941gmail-m_-597234831199625208gmail-m_7337395877569710517gmail-m_6259310096911551287gmail-m_1094472000501772005gmail-m_3468206820950415506gmail-m_-7933021170587843311cid:f_l02lscsb0"><log.txt></span></div></blockquote></div><br></div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><font size="1" face="tahoma, sans-serif">Giovane Avancini</font><div><font size="1" face="tahoma, sans-serif">Doutorando em Engenharia de Estruturas - Escola de Engenharia de São Carlos, USP</font></div><div><font size="1" face="tahoma, sans-serif"><br></font></div><div><font size="1" face="tahoma, sans-serif">PhD researcher in Structural Engineering - School of Engineering of São Carlos. USP</font></div></div></div></div></div>
<span id="gmail-m_8395500376552529656gmail-m_-7764169804948922721gmail-m_8734375473004278970gmail-m_-5704634044864832034gmail-m_7227961845865744941gmail-m_-597234831199625208gmail-m_7337395877569710517cid:f_l02w1pdt0"><log.txt></span><span id="gmail-m_8395500376552529656gmail-m_-7764169804948922721gmail-m_8734375473004278970gmail-m_-5704634044864832034gmail-m_7227961845865744941gmail-m_-597234831199625208gmail-m_7337395877569710517cid:f_l02wc3pz1"><patch.png></span></div></blockquote></div><br></div></div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><font size="1" face="tahoma, sans-serif">Giovane Avancini</font><div><font size="1" face="tahoma, sans-serif">Doutorando em Engenharia de Estruturas - Escola de Engenharia de São Carlos, USP</font></div><div><font size="1" face="tahoma, sans-serif"><br></font></div><div><font size="1" face="tahoma, sans-serif">PhD researcher in Structural Engineering - School of Engineering of São Carlos. USP</font></div></div></div></div></div>
</div></blockquote></div><br></div></div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><font size="1" face="tahoma, sans-serif">Giovane Avancini</font><div><font size="1" face="tahoma, sans-serif">Doutorando em Engenharia de Estruturas - Escola de Engenharia de São Carlos, USP</font></div><div><font size="1" face="tahoma, sans-serif"><br></font></div><div><font size="1" face="tahoma, sans-serif">PhD researcher in Structural Engineering - School of Engineering of São Carlos. USP</font></div></div></div></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><font size="1" face="tahoma, sans-serif">Giovane Avancini</font><div><font size="1" face="tahoma, sans-serif">Doutorando em Engenharia de Estruturas - Escola de Engenharia de São Carlos, USP</font></div><div><font size="1" face="tahoma, sans-serif"><br></font></div><div><font size="1" face="tahoma, sans-serif">PhD researcher in Structural Engineering - School of Engineering of São Carlos. USP</font></div></div></div></div></div>
<span id="gmail-m_8395500376552529656gmail-m_-7764169804948922721cid:f_l0hdaaoh0"><log.txt></span></div></blockquote></div><br></div></div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><font size="1" face="tahoma, sans-serif">Giovane Avancini</font><div><font size="1" face="tahoma, sans-serif">Doutorando em Engenharia de Estruturas - Escola de Engenharia de São Carlos, USP</font></div><div><font size="1" face="tahoma, sans-serif"><br></font></div><div><font size="1" face="tahoma, sans-serif">PhD researcher in Structural Engineering - School of Engineering of São Carlos. USP</font></div></div></div></div></div>
</div></blockquote></div><br></div></div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><font size="1" face="tahoma, sans-serif">Giovane Avancini</font><div><font size="1" face="tahoma, sans-serif">Doutorando em Engenharia de Estruturas - Escola de Engenharia de São Carlos, USP</font></div><div><font size="1" face="tahoma, sans-serif"><br></font></div><div><font size="1" face="tahoma, sans-serif">PhD researcher in Structural Engineering - School of Engineering of São Carlos. USP</font></div></div></div></div></div>