The default behavior previously was the flip of the current behavior. By the way, we also now have much better performance if you do not preallocate (not as good as with perfect preallocation, but much better than in ancient history; you simply do not preallocate to get this behavior).
Barry > On Jul 11, 2024, at 4:51 PM, Michael Povolotskyi <[email protected]> wrote: > > Thanks a lot. > > Is this a new feature? It seems to me that 10 years ago the default behavior > was different. > > Michael. > > On 7/11/2024 4:04 PM, Barry Smith wrote: >> >> By default, if you preallocate but not enough, it will automatically error >> unless you call MatSetOption(mat,MAT_NEW_NONZERO_ALLOCATION_ERR,PETSC_FALSE); >> >> >>> On Jul 11, 2024, at 4:02 PM, Michael Povolotskyi <[email protected]> >>> <mailto:[email protected]> wrote: >>> >>> Thank you, >>> >>> let me clarify my question. >>> >>> Imagine that I have a sparse matrix, and the number of non zero entries >>> that I specified is too small. >>> >>> I know that I can insert values in it but it will be slow. >>> >>> I remember there was a way to make PETSC to throw an error if a number of >>> non zero elements per row was bigger that was preallocated. Then I could >>> fix my algorithm. Is this functionality available with the current version? >>> >>> Michael. >>> >>> On 7/11/2024 3:55 PM, Barry Smith wrote: >>>> >>>> MatGetInfo() is the programmatic interface used to get this information. >>>> You can also run a proggram with -info and grep for malloc. >>>> >>>> Barry >>>> >>>> >>>>> On Jul 11, 2024, at 1:55 PM, Michael Povolotskyi <[email protected]> >>>>> <mailto:[email protected]> wrote: >>>>> >>>>> This Message Is From an External Sender >>>>> This message came from outside your organization. >>>>> Hello, >>>>> >>>>> is there an option in PETSC that allows to check at run time if a sparse >>>>> matrix has been preallocated correctly? I remember there was something >>>>> like that is the older versions, but cannot find it now. >>>>> >>>>> The goal is to get rid of any possible time overhead due to dynamic >>>>> preallocation. >>>>> >>>>> Thank you, >>>>> >>>>> Michael. >>>>> >>>>> >>>> >>
