November 2016 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Strange behaviour from TSARKIMEX
by Stefano Zampini 15 Nov '16

15 Nov '16

Emil, I have modifed the example code to also include the convection matrix in the lhs. Plain arkimex with -ts_arkimex_fully_implicit false and M*udot - K*u in the lhs works well. Trying to summarize the thread, it seems that we may have problems using arkimex with default parameters when F(u,udot,t) will just depend on udot and not on u. If this is the case, is the user supposed to write G(t,u) as F_udot ^(-1) g(t,u)? So why not provide an API to allow it, instead to have the user modify the G function? Also, wouldn’t be better to have standard SDIRK the default? i.e. -ts_arkimex_fully_implicit false? Stefano On Nov 14, 2016, at 11:11 PM, Emil Constantinescu <emconsta(a)mcs.anl.gov> wrote: > > > On 11/14/16 1:17 PM, Stefano Zampini wrote: > > I do have pasted the output for ts_monitor for the first three steps. > > I meant -ts_adapt_monitor, I wanted to see what TS solvers are used: The first step is probably an Euler method, that's why you have 10 SNES solves in place of 7 for the later ones. > > > The entry you are referring to in Table 11 actually breaks the TS > > assumption that the ODE can be written F(u,udot,t) = G(u,t) (I was > > thinking it was a typo) > > It works for certain forms as listed in the table. I'm not aware of any RK method that handles this case with G(u,t) treated explicitly. > >>> In your case, you would either use the setup corresponding to "stiff >>> ODE w/ mass matrix" or "nonstiff ODE w/ mass matrix”. >> >> I’m not interested in solving this specific advection problem with >> arkimex. I came across this problem when writing a general interface to >> TS from a FEM library. > > Normally, I do that by solving udot=M^-1 f(u) + M^-1 g(u) > >>> It is difficult to create a decision tree for every way of writing the >>> splittings. Do you find Table 11 not clear about what splitting to >>> use? I would welcome any kind of feedback for improving it. >>> >> >> If the entry in Table 11 is correct, please add a comment on the manual >> stating that ARKIMEX does not fully support the F(u,udot,t) = G(u,t) >> interface. > > I see how the first statement in the caption can be confusing; The last statement in the caption states: > "General cases such as F(t;y;y')=G(t;y) are not amenable to IMEX Runge-Kutta, but can be solved by using fully implicit methods." A line in the table may be more clear. I'll go for that. > > Emil

1 0

Re: [petsc-dev] Strange behaviour from TSARKIMEX
by Emil Constantinescu 14 Nov '16

14 Nov '16

On 11/14/16 1:17 PM, Stefano Zampini wrote: > I do have pasted the output for ts_monitor for the first three steps. I meant -ts_adapt_monitor, I wanted to see what TS solvers are used: The first step is probably an Euler method, that's why you have 10 SNES solves in place of 7 for the later ones. > The entry you are referring to in Table 11 actually breaks the TS > assumption that the ODE can be written F(u,udot,t) = G(u,t) (I was > thinking it was a typo) It works for certain forms as listed in the table. I'm not aware of any RK method that handles this case with G(u,t) treated explicitly. >> In your case, you would either use the setup corresponding to "stiff >> ODE w/ mass matrix" or "nonstiff ODE w/ mass matrixï¿½. > > Iï¿½m not interested in solving this specific advection problem with > arkimex. I came across this problem when writing a general interface to > TS from a FEM library. Normally, I do that by solving udot=M^-1 f(u) + M^-1 g(u) >> It is difficult to create a decision tree for every way of writing the >> splittings. Do you find Table 11 not clear about what splitting to >> use? I would welcome any kind of feedback for improving it. >> > > If the entry in Table 11 is correct, please add a comment on the manual > stating that ARKIMEX does not fully support the F(u,udot,t) = G(u,t) > interface. I see how the first statement in the caption can be confusing; The last statement in the caption states: "General cases such as F(t;y;y')=G(t;y) are not amenable to IMEX Runge-Kutta, but can be solved by using fully implicit methods." A line in the table may be more clear. I'll go for that. Emil

1 0

Re: [petsc-dev] problem with TSIRM in PETSc
by Barry Smith 14 Nov '16

14 Nov '16

> On Nov 14, 2016, at 10:53 AM, Raphaël Couturier <raphael.couturier(a)univ-fcomte.fr> wrote: > > This version is the correct version > https://bitbucket.org/petsc/petsc/history-node/1f2c6fc4275e/src/ksp/ksp/imp… > > The petsc-3.7.4.tar.gz is different. Line 68 there is a, for example: > ierr = PetscMalloc(tsirm->Iend-tsirm->Istart,&ind_row);CHKERRQ(ierr); This is incorrect. And will result in memory corruption, the one below is correct. > > > In the bitbucket version Line 64 it is > ierr = PetscMalloc1(tsirm->Iend-tsirm->Istart,&ind_row);CHKERRQ(ierr); > > > There are other differences Likely we found these bugs and fixed them in master but not in maint. Barry > > So we wonder whether it is normal or not. > Thank you > > Raphaël >> And you an see the history of the tsirm.c file (in the master branch) >> on bitbucket, which might make that easier: >> >> https://bitbucket.org/petsc/petsc/history-node/1f2c6fc4275e/src/ksp/ksp/imp… >> >> >> >> On Mon, Nov 14, 2016 at 5:31 PM, Matthew Knepley >> <knepley(a)gmail.com> >> wrote: >> >>> On Mon, Nov 14, 2016 at 2:29 AM, Raphaël Couturier >>> >>> <raphael.couturier(a)univ-fcomte.fr> >>> wrote: >>> >>>> Hello all, >>>> >>>> We have submitted a code for TSIRM a new method to solve linear systems in >>>> PETSc, approximately one year ago, and we have a question. The code is >>>> different between the petsc version in bitbucket and in the last PETSc >>>> archive. In fact everything is working fine in the petsc version but not in >>>> the petsc-3.7.4. When we submitted the first version, it seemed that >>>> everything was fine for this part of the code. What could we do? Resubmit a >>>> new version? Wait the next PETSc release? >>>> >>> It would really help if you could give the SHA1 for the two versions you are >>> talking about. >>> >>> Thanks, >>> >>> Matt >>> >>>> Thank you in advance for your answer. >>>> >>>> Raphaël >>>> >>> >>> >>> >>> -- >>> What most experimenters take for granted before they begin their experiments >>> is infinitely more interesting than any results to which their experiments >>> lead. >>> -- Norbert Wiener >>> >

1 0

Re: [petsc-dev] [petsc-users] Shell preconditioner within a fieldsplit
by Jed Brown 14 Nov '16

14 Nov '16

Patrick Sanan <patrick.sanan(a)gmail.com> writes: > PCMAT seems abstraction-breaking (and the man page even admits it is > "strange" :D ) > > The preconditioner Mat B is thought of as an approximation (maybe a > perfect one) to the operator A, Pmat (B) is just data used to construct the preconditioner. > to be used to construct preconditioners. PCMAT uses B as an > approximation to the *inverse* of A (loosely speaking). That's > confusing, and worse it ruins a central feature of PETSc, which is the > ability to change the preconditioner at runtime; the meaning of B > changes depending on which PC implementation you use. I agree that it cripples the ability to swap PC. > Proposed change: Have PCMAT (like analogous object PCKSP) store its > own Mat object and introduce API functions to interact with this > internal Mat. To make sure that any user code which happens to use > PCMAT doesn't see an unexplained change in behavior, do not set a > default internal Mat, and produce an informative error if > PCApply_Mat() is called without first calling the new function > PCMatSetMat(). Interacting directy with the PC sucks for nested systems. You could have MatSetPC(mat,minv) and have PCMAT (or whatever) pull it out.

1 0

Re: [petsc-dev] Strange behaviour from TSARKIMEX
by Stefano Zampini 14 Nov '16

14 Nov '16

> > Sorry, the equation type is needed for when the fully implicit option is used. > the output with -m_lhs -ts_type arkimex -ts_arkimex_type 5 -ts_arkimex_fully_implicit (case a) ) is different from -m_lhs 0 -ts_type arkimex -ts_arkimex_type 5 -ts_arkimex_fully_implicit (case b) ) > I assume you are in the b) case, No, case a) mass matrix on the left-hand side > that would correspond to "mass & stiff-nonstiff ODE" entry in Table 11 with f(t,y)=0. Have you tried the forms suggested there, they are slightly different from what you indicate in your original message for case b)? Also, please use -ts_monitor and comment out the equation type. > I do have pasted the output for ts_monitor for the first three steps. The entry you are referring to in Table 11 actually breaks the TS assumption that the ODE can be written F(u,udot,t) = G(u,t) (I was thinking it was a typo) Indeed, using what is listed in Table 11 for the case "mass & stiff-nonstiff ODE", we have ODE: M * ydot = g(t,y) + f(t,y), F = M * ydot - f(t,u), G = M^-1 * g(t,y) Putting F and G in the form F(u,udot,t) = G(u,t), we will have the ODE M * ydot = f(t,u) + M^-1 * g(t,y) > In your case, you would either use the setup corresponding to "stiff ODE w/ mass matrix" or "nonstiff ODE w/ mass matrix”. I’m not interested in solving this specific advection problem with arkimex. I came across this problem when writing a general interface to TS from a FEM library. > It is difficult to create a decision tree for every way of writing the splittings. Do you find Table 11 not clear about what splitting to use? I would welcome any kind of feedback for improving it. > If the entry in Table 11 is correct, please add a comment on the manual stating that ARKIMEX does not fully support the F(u,udot,t) = G(u,t) interface. > Thanks, > Emil > > On 11/14/16 11:45 AM, Stefano Zampini wrote: >> Emil, >> >> thanks for the explanations. I’ve added >> TSSetEquationType(ts,TS_EQ_IMPLICIT) and things actually got worse with >> arkimex. >> Adding -ts_arkimex_fully_implicit still gives the same inconsistency. >> >> Running with -m_lhs -snes_monitor -ts_type arkimex -ts_arkimex_type 5, >> it reports for the first three TSSteps >> >> 0 TS dt 0.01 time 0. >> 0 SNES Function norm 2.881332954700e-01 >> 1 SNES Function norm 5.764785317497e-16 >> 0 SNES Function norm 2.656435502730e-01 >> 1 SNES Function norm 1.351993391899e-15 >> 0 SNES Function norm 2.748681648224e-01 >> 1 SNES Function norm 9.153705366186e-16 >> 0 SNES Function norm 2.654405587243e-01 >> 1 SNES Function norm 2.165715847788e-15 >> 0 SNES Function norm 1.327202793622e-01 >> 1 SNES Function norm 1.851465123731e-15 >> 0 SNES Function norm 3.703291910243e-02 >> 1 SNES Function norm 1.946066132445e-15 >> 0 SNES Function norm 2.917498324433e-01 >> 1 SNES Function norm 1.680056316341e-15 >> 0 SNES Function norm 1.972362337024e-01 >> 1 SNES Function norm 1.055632173875e-15 >> 0 SNES Function norm 4.087125686933e-02 >> 1 SNES Function norm 2.555645968009e-15 >> 0 SNES Function norm 3.547915829559e-01 >> 1 SNES Function norm 2.103175616151e-15 >> 2 TS dt 0.01 time 0.02 >> 0 SNES Function norm 1.965807268111e-15 >> 1 SNES Function norm 0.000000000000e+00 >> 0 SNES Function norm 1.597532788386e-19 >> 1 SNES Function norm 0.000000000000e+00 >> 0 SNES Function norm 1.965807242146e-15 >> 1 SNES Function norm 0.000000000000e+00 >> 0 SNES Function norm 3.815060728816e-15 >> 1 SNES Function norm 7.476292242926e-16 >> 0 SNES Function norm 1.837692463276e-15 >> 1 SNES Function norm 0.000000000000e+00 >> 0 SNES Function norm 0.000000000000e+00 >> 0 SNES Function norm 1.965807300567e-15 >> 1 SNES Function norm 0.000000000000e+00 >> 3 TS dt 0.01 time 0.03 >> 0 SNES Function norm 0.000000000000e+00 >> 0 SNES Function norm 0.000000000000e+00 >> 0 SNES Function norm 0.000000000000e+00 >> 0 SNES Function norm 0.000000000000e+00 >> 0 SNES Function norm 0.000000000000e+00 >> 0 SNES Function norm 0.000000000000e+00 >> 0 SNES Function norm 0.000000000000e+00 >> >> Then, all the other SNES function norms are zero. >> >> >> >> On Nov 14, 2016, at 6:23 PM, Emil Constantinescu <emconsta(a)mcs.anl.gov >> <mailto:[email protected]>> wrote: >> >>> Stefano, thanks for your note. The consistent splittings currently >>> supported under ts_type arkimex are give in Table 11 in the manual: >>> http://www.mcs.anl.gov/petsc/petsc-current/docs/manual.pdf >>> >>> Your case a) is not treated as you wrote it down. The reasoning behind >>> the use cases is that M will have to be inverted directly or >>> indirectly if you put it in F(...) because it's in implicit ODE. In >>> your case b) you handle that directly; however, in case a) the M in >>> F(...) is ignored in some steps leading to inconsistent formulations. >>> That being said, there are ways of solving it as in case a) if M is >>> full rank: some hints are in the caption in Table 11, but I can expand. >>> >>> Also in Table 11, there is a note about instructing TS that the user >>> is specifying an implicit ODE (M*ydot....): " set TSSetEquationType() >>> to TS_EQ_IMPLICIT or higher". That sould solve the >>> -ts_arkimex_fully_implicit inconsistency issue. >>> >>> Emil >>> >>> >>> On 11/14/16 4:09 AM, Stefano Zampini wrote: >>>> I came across this thing recently, and I couldn't figure out where the >>>> issue could be. >>>> >>>> The problem I'm solving is a simple DG advection, the ode is M*udot = >>>> K*u+b, M is diagonal. >>>> >>>> Attached is a MWE that reproduces the problem. >>>> >>>> The problem is formed in two different cases depending on the command >>>> line option -m_lhs >>>> >>>> a) -m_lhs 1 : F(u,udot,t) = M*udot, G(u,t) = K*u+b >>>> b) -m_lhs 0 : F(u,udot,t) = udot, G(u,t) = M^-1(K*u+b) >>>> >>>> Using option b) and RK4, the solution is ok. >>>> If run with any implicit TS method except arkimex, no matter if I'm >>>> choosing option a) or b), the solution is always very close (say, final >>>> error < 0.05) to the expected one (computed with BDF). >>>> >>>> When using ARKIMEX, case b) gives a good solution, but not case a). In >>>> fact, the solution does not seem to be advected at all in this case. >>>> >>>> I was wondering if I'm doing something wrong or there's a bug in the >>>> ARKIMEX implementation. >>>> >>>> I also noticed that, using -ts_arkimex_fully_implicit does not produce >>>> the same output for case a) and b). Shouldn't they produce the same >>>> method with this option? >>>> >>>> Thanks, >>>> -- >>>> Stefano >>> <1_Warning.txt>

1 0

Re: [petsc-dev] Extending MatLRC
by Jed Brown 14 Nov '16

14 Nov '16

Barry Smith <bsmith(a)mcs.anl.gov> writes: > Go ahead and extend it. Presumably to A + X C Y'. >> On Nov 14, 2016, at 6:14 AM, Jose E. Roman <jroman(a)dsic.upv.es> wrote: >> >> Hi. >> >> I need to work with low-rank matrices represented as the outer product of tall-skinny matrices. Specifically, I need to cover these cases: >> - Symmetric positive-definite: X*X' >> - Symmetric indefinite: X*C*X' >> - Non-symmetric: X*Y' (or maybe X*C*Y') >> >> This could be added by extending MATLRC (allowing A to be NULL). If you agree I could create a pull request. If you prefer to keep MATLRC as it is now, I could add this to SLEPc. >> >> Jose >>

1 0

Re: [petsc-dev] Strange behaviour from TSARKIMEX
by Emil Constantinescu 14 Nov '16

14 Nov '16

Stefano, Sorry, the equation type is needed for when the fully implicit option is used. I assume you are in the b) case, that would correspond to "mass & stiff-nonstiff ODE" entry in Table 11 with f(t,y)=0. Have you tried the forms suggested there, they are slightly different from what you indicate in your original message for case b)? Also, please use -ts_monitor and comment out the equation type. In your case, you would either use the setup corresponding to "stiff ODE w/ mass matrix" or "nonstiff ODE w/ mass matrix". It is difficult to create a decision tree for every way of writing the splittings. Do you find Table 11 not clear about what splitting to use? I would welcome any kind of feedback for improving it. Thanks, Emil On 11/14/16 11:45 AM, Stefano Zampini wrote: > Emil, > > thanks for the explanations. Iï¿½ve added > TSSetEquationType(ts,TS_EQ_IMPLICIT) and things actually got worse with > arkimex. > Adding -ts_arkimex_fully_implicit still gives the same inconsistency. > > Running with -m_lhs -snes_monitor -ts_type arkimex -ts_arkimex_type 5, > it reports for the first three TSSteps > > 0 TS dt 0.01 time 0. > 0 SNES Function norm 2.881332954700e-01 > 1 SNES Function norm 5.764785317497e-16 > 0 SNES Function norm 2.656435502730e-01 > 1 SNES Function norm 1.351993391899e-15 > 0 SNES Function norm 2.748681648224e-01 > 1 SNES Function norm 9.153705366186e-16 > 0 SNES Function norm 2.654405587243e-01 > 1 SNES Function norm 2.165715847788e-15 > 0 SNES Function norm 1.327202793622e-01 > 1 SNES Function norm 1.851465123731e-15 > 0 SNES Function norm 3.703291910243e-02 > 1 SNES Function norm 1.946066132445e-15 > 0 SNES Function norm 2.917498324433e-01 > 1 SNES Function norm 1.680056316341e-15 > 0 SNES Function norm 1.972362337024e-01 > 1 SNES Function norm 1.055632173875e-15 > 0 SNES Function norm 4.087125686933e-02 > 1 SNES Function norm 2.555645968009e-15 > 0 SNES Function norm 3.547915829559e-01 > 1 SNES Function norm 2.103175616151e-15 > 2 TS dt 0.01 time 0.02 > 0 SNES Function norm 1.965807268111e-15 > 1 SNES Function norm 0.000000000000e+00 > 0 SNES Function norm 1.597532788386e-19 > 1 SNES Function norm 0.000000000000e+00 > 0 SNES Function norm 1.965807242146e-15 > 1 SNES Function norm 0.000000000000e+00 > 0 SNES Function norm 3.815060728816e-15 > 1 SNES Function norm 7.476292242926e-16 > 0 SNES Function norm 1.837692463276e-15 > 1 SNES Function norm 0.000000000000e+00 > 0 SNES Function norm 0.000000000000e+00 > 0 SNES Function norm 1.965807300567e-15 > 1 SNES Function norm 0.000000000000e+00 > 3 TS dt 0.01 time 0.03 > 0 SNES Function norm 0.000000000000e+00 > 0 SNES Function norm 0.000000000000e+00 > 0 SNES Function norm 0.000000000000e+00 > 0 SNES Function norm 0.000000000000e+00 > 0 SNES Function norm 0.000000000000e+00 > 0 SNES Function norm 0.000000000000e+00 > 0 SNES Function norm 0.000000000000e+00 > > Then, all the other SNES function norms are zero. > > > > On Nov 14, 2016, at 6:23 PM, Emil Constantinescu <emconsta(a)mcs.anl.gov > <mailto:[email protected]>> wrote: > >> Stefano, thanks for your note. The consistent splittings currently >> supported under ts_type arkimex are give in Table 11 in the manual: >> http://www.mcs.anl.gov/petsc/petsc-current/docs/manual.pdf >> >> Your case a) is not treated as you wrote it down. The reasoning behind >> the use cases is that M will have to be inverted directly or >> indirectly if you put it in F(...) because it's in implicit ODE. In >> your case b) you handle that directly; however, in case a) the M in >> F(...) is ignored in some steps leading to inconsistent formulations. >> That being said, there are ways of solving it as in case a) if M is >> full rank: some hints are in the caption in Table 11, but I can expand. >> >> Also in Table 11, there is a note about instructing TS that the user >> is specifying an implicit ODE (M*ydot....): " set TSSetEquationType() >> to TS_EQ_IMPLICIT or higher". That sould solve the >> -ts_arkimex_fully_implicit inconsistency issue. >> >> Emil >> >> >> On 11/14/16 4:09 AM, Stefano Zampini wrote: >>> I came across this thing recently, and I couldn't figure out where the >>> issue could be. >>> >>> The problem I'm solving is a simple DG advection, the ode is M*udot = >>> K*u+b, M is diagonal. >>> >>> Attached is a MWE that reproduces the problem. >>> >>> The problem is formed in two different cases depending on the command >>> line option -m_lhs >>> >>> a) -m_lhs 1 : F(u,udot,t) = M*udot, G(u,t) = K*u+b >>> b) -m_lhs 0 : F(u,udot,t) = udot, G(u,t) = M^-1(K*u+b) >>> >>> Using option b) and RK4, the solution is ok. >>> If run with any implicit TS method except arkimex, no matter if I'm >>> choosing option a) or b), the solution is always very close (say, final >>> error < 0.05) to the expected one (computed with BDF). >>> >>> When using ARKIMEX, case b) gives a good solution, but not case a). In >>> fact, the solution does not seem to be advected at all in this case. >>> >>> I was wondering if I'm doing something wrong or there's a bug in the >>> ARKIMEX implementation. >>> >>> I also noticed that, using -ts_arkimex_fully_implicit does not produce >>> the same output for case a) and b). Shouldn't they produce the same >>> method with this option? >>> >>> Thanks, >>> -- >>> Stefano >> <1_Warning.txt> >

1 0

Re: [petsc-dev] Extending MatLRC
by Barry Smith 14 Nov '16

14 Nov '16

Go ahead and extend it. > On Nov 14, 2016, at 6:14 AM, Jose E. Roman <jroman(a)dsic.upv.es> wrote: > > Hi. > > I need to work with low-rank matrices represented as the outer product of tall-skinny matrices. Specifically, I need to cover these cases: > - Symmetric positive-definite: X*X' > - Symmetric indefinite: X*C*X' > - Non-symmetric: X*Y' (or maybe X*C*Y') > > This could be added by extending MATLRC (allowing A to be NULL). If you agree I could create a pull request. If you prefer to keep MATLRC as it is now, I could add this to SLEPc. > > Jose >

1 0

Re: [petsc-dev] Strange behaviour from TSARKIMEX
by Stefano Zampini 14 Nov '16

14 Nov '16

Emil, thanks for the explanations. I’ve added TSSetEquationType(ts,TS_EQ_IMPLICIT) and things actually got worse with arkimex. Adding -ts_arkimex_fully_implicit still gives the same inconsistency. Running with -m_lhs -snes_monitor -ts_type arkimex -ts_arkimex_type 5, it reports for the first three TSSteps 0 TS dt 0.01 time 0. 0 SNES Function norm 2.881332954700e-01 1 SNES Function norm 5.764785317497e-16 0 SNES Function norm 2.656435502730e-01 1 SNES Function norm 1.351993391899e-15 0 SNES Function norm 2.748681648224e-01 1 SNES Function norm 9.153705366186e-16 0 SNES Function norm 2.654405587243e-01 1 SNES Function norm 2.165715847788e-15 0 SNES Function norm 1.327202793622e-01 1 SNES Function norm 1.851465123731e-15 0 SNES Function norm 3.703291910243e-02 1 SNES Function norm 1.946066132445e-15 0 SNES Function norm 2.917498324433e-01 1 SNES Function norm 1.680056316341e-15 0 SNES Function norm 1.972362337024e-01 1 SNES Function norm 1.055632173875e-15 0 SNES Function norm 4.087125686933e-02 1 SNES Function norm 2.555645968009e-15 0 SNES Function norm 3.547915829559e-01 1 SNES Function norm 2.103175616151e-15 2 TS dt 0.01 time 0.02 0 SNES Function norm 1.965807268111e-15 1 SNES Function norm 0.000000000000e+00 0 SNES Function norm 1.597532788386e-19 1 SNES Function norm 0.000000000000e+00 0 SNES Function norm 1.965807242146e-15 1 SNES Function norm 0.000000000000e+00 0 SNES Function norm 3.815060728816e-15 1 SNES Function norm 7.476292242926e-16 0 SNES Function norm 1.837692463276e-15 1 SNES Function norm 0.000000000000e+00 0 SNES Function norm 0.000000000000e+00 0 SNES Function norm 1.965807300567e-15 1 SNES Function norm 0.000000000000e+00 3 TS dt 0.01 time 0.03 0 SNES Function norm 0.000000000000e+00 0 SNES Function norm 0.000000000000e+00 0 SNES Function norm 0.000000000000e+00 0 SNES Function norm 0.000000000000e+00 0 SNES Function norm 0.000000000000e+00 0 SNES Function norm 0.000000000000e+00 0 SNES Function norm 0.000000000000e+00 Then, all the other SNES function norms are zero. On Nov 14, 2016, at 6:23 PM, Emil Constantinescu <emconsta(a)mcs.anl.gov> wrote: > Stefano, thanks for your note. The consistent splittings currently supported under ts_type arkimex are give in Table 11 in the manual: http://www.mcs.anl.gov/petsc/petsc-current/docs/manual.pdf > > Your case a) is not treated as you wrote it down. The reasoning behind the use cases is that M will have to be inverted directly or indirectly if you put it in F(...) because it's in implicit ODE. In your case b) you handle that directly; however, in case a) the M in F(...) is ignored in some steps leading to inconsistent formulations. That being said, there are ways of solving it as in case a) if M is full rank: some hints are in the caption in Table 11, but I can expand. > > Also in Table 11, there is a note about instructing TS that the user is specifying an implicit ODE (M*ydot....): " set TSSetEquationType() to TS_EQ_IMPLICIT or higher". That sould solve the -ts_arkimex_fully_implicit inconsistency issue. > > Emil > > > On 11/14/16 4:09 AM, Stefano Zampini wrote: >> I came across this thing recently, and I couldn't figure out where the >> issue could be. >> >> The problem I'm solving is a simple DG advection, the ode is M*udot = >> K*u+b, M is diagonal. >> >> Attached is a MWE that reproduces the problem. >> >> The problem is formed in two different cases depending on the command >> line option -m_lhs >> >> a) -m_lhs 1 : F(u,udot,t) = M*udot, G(u,t) = K*u+b >> b) -m_lhs 0 : F(u,udot,t) = udot, G(u,t) = M^-1(K*u+b) >> >> Using option b) and RK4, the solution is ok. >> If run with any implicit TS method except arkimex, no matter if I'm >> choosing option a) or b), the solution is always very close (say, final >> error < 0.05) to the expected one (computed with BDF). >> >> When using ARKIMEX, case b) gives a good solution, but not case a). In >> fact, the solution does not seem to be advected at all in this case. >> >> I was wondering if I'm doing something wrong or there's a bug in the >> ARKIMEX implementation. >> >> I also noticed that, using -ts_arkimex_fully_implicit does not produce >> the same output for case a) and b). Shouldn't they produce the same >> method with this option? >> >> Thanks, >> -- >> Stefano > <1_Warning.txt>

1 0

Re: [petsc-dev] problem with TSIRM in PETSc
by Raphaël Couturier 14 Nov '16

14 Nov '16

This version is the correct version https://bitbucket.org/petsc/petsc/history-node/1f2c6fc4275e/src/ksp/ksp/imp… The petsc-3.7.4.tar.gz is different. Line 68 there is a, for example: ierr = PetscMalloc(tsirm->Iend-tsirm->Istart,&ind_row);CHKERRQ(ierr); In the bitbucket version Line 64 it is ierr = PetscMalloc1(tsirm->Iend-tsirm->Istart,&ind_row);CHKERRQ(ierr); There are other differences So we wonder whether it is normal or not. Thank you Raphaël > And you an see the history of the tsirm.c file (in the master branch) > on bitbucket, which might make that easier: > https://bitbucket.org/petsc/petsc/history-node/1f2c6fc4275e/src/ksp/ksp/imp… > > > On Mon, Nov 14, 2016 at 5:31 PM, Matthew Knepley <knepley(a)gmail.com> wrote: >> On Mon, Nov 14, 2016 at 2:29 AM, Raphaël Couturier >> <raphael.couturier(a)univ-fcomte.fr> wrote: >>> Hello all, >>> >>> We have submitted a code for TSIRM a new method to solve linear systems in >>> PETSc, approximately one year ago, and we have a question. The code is >>> different between the petsc version in bitbucket and in the last PETSc >>> archive. In fact everything is working fine in the petsc version but not in >>> the petsc-3.7.4. When we submitted the first version, it seemed that >>> everything was fine for this part of the code. What could we do? Resubmit a >>> new version? Wait the next PETSc release? >> It would really help if you could give the SHA1 for the two versions you are >> talking about. >> >> Thanks, >> >> Matt >>> Thank you in advance for your answer. >>> >>> Raphaël >> >> >> >> -- >> What most experimenters take for granted before they begin their experiments >> is infinitely more interesting than any results to which their experiments >> lead. >> -- Norbert Wiener

1 0