Re: [petsc-users] Finite difference approximation of Jacobian

On Tue, Jan 11, 2022 at 12:09 PM Patrick Sanan wrote: > Working on doing this incrementally, in progress here: > https://gitlab.com/petsc/petsc/-/merge_requests/4712 > > This works in 1D for AIJ matrices, assembling a matrix with a maximal > number of zero entries as dictated by the stencil

Re: [petsc-users] Finite difference approximation of Jacobian

> On Jan 12, 2022, at 2:22 AM, Jed Brown wrote: > > Because if a user jumps right into MatSetValues() and then wants to use the > result, it better have the values. It's true that DM preallocation normally > just "inserts zeros" and thus matches what MATPREALLOCATOR does. I am not saying

Re: [petsc-users] Finite difference approximation of Jacobian

I agree with this and even started a branch jed/mat-hash in (yikes!) 2017. I think it should be default if no preallocation functions are called. But it isn't exactly the MATPREALLOCATOR code because it needs to handle values too. Should not be a lot of code and will essentially remove this FAQ

Re: [petsc-users] Finite difference approximation of Jacobian

Because if a user jumps right into MatSetValues() and then wants to use the result, it better have the values. It's true that DM preallocation normally just "inserts zeros" and thus matches what MATPREALLOCATOR does. Barry Smith writes: > Why does it need to handle values? > >> On Jan 12,

Re: [petsc-users] Finite difference approximation of Jacobian

This is something I almost started a while ago. https://gitlab.com/petsc/petsc/-/issues/852 It would be a very interesting addition to us. Fande > On Jan 12, 2022, at 12:04 AM, Barry Smith wrote: > >  > Why does it need to handle values? > >> On Jan 12, 2022, at 12:43 AM, Jed Brown

Re: [petsc-users] PCSetCoordinates does not set coordinates of sub PC (fieldsplit) objects

On Tue, Jan 11, 2022 at 3:31 PM Barry Smith wrote: > > Nicolas, > > For "simple" PCFIELDSPLIT it is possible to pass down the attached > coordinate information. By simple I mean where the splitting is done by > fields and not by general lists of IS (where one does not have enough >

Re: [petsc-users] A problem with MatFDColoringSetFunction

> On Jan 11, 2022, at 8:04 PM, Jed Brown wrote: > > Barry Smith writes: > >> Thanks for the alternative. >> >> @jed does this mean we need to do our casting of functions like this >> everywhere? > > Whenever our interfaces accept a function with a non-unique prototype, the >

Re: [petsc-users] PCSetCoordinates does not set coordinates of sub PC (fieldsplit) objects

> On Jan 11, 2022, at 9:51 PM, Matthew Knepley wrote: > > On Tue, Jan 11, 2022 at 3:31 PM Barry Smith > wrote: > > Nicolas, > > For "simple" PCFIELDSPLIT it is possible to pass down the attached > coordinate information. By simple I mean where the splitting

Re: [petsc-users] Fluid-Structure interaction with multiple DMPlex

Matthew Knepley writes: > Hmm, let's start here because that does not make sense to me. Can you write > down the mathematical model? Usually I think of temperature as being > a continuous field. I have only seen discontinuities for rareified gases. Well, you can still model it as a

Re: [petsc-users] Fluid-Structure interaction with multiple DMPlex

On Tue, Jan 11, 2022 at 2:59 PM Thibault Bridel-Bertomeu < thibault.bridelberto...@gmail.com> wrote: > Le mar. 11 janv. 2022 à 16:36, Jed Brown a écrit : > >> Thibault Bridel-Bertomeu writes: >> >> > Hello everybody, >> > >> > So, let's say i have the mesh attached to this email that has 2

Re: [petsc-users] Finite difference approximation of Jacobian

Actually given the Subject of this email "Finite difference approximation of Jacobian" what I suggested is A complete story anyways for Patrick since the user cannot provide numerical values (of course Patrick could write a general new hash matrix type and then use it with zeros but that is

Re: [petsc-users] Finite difference approximation of Jacobian

I think the MATPREALLOCATOR as a MatType is a cumbersome strange thing and would prefer it was just functionality that Mat provided directly; for example MatSetOption(mat, preallocator_mode,true); matsetvalues,... MatAssemblyBegin/End. Now the matrix has its proper nonzero structure of

Re: [petsc-users] Finite difference approximation of Jacobian

Why does it need to handle values? > On Jan 12, 2022, at 12:43 AM, Jed Brown wrote: > > I agree with this and even started a branch jed/mat-hash in (yikes!) 2017. I > think it should be default if no preallocation functions are called. But it > isn't exactly the MATPREALLOCATOR code

Re: [petsc-users] Finite difference approximation of Jacobian

Working on doing this incrementally, in progress here: https://gitlab.com/petsc/petsc/-/merge_requests/4712 This works in 1D for AIJ matrices, assembling a matrix with a maximal number of zero entries as dictated by the stencil width (which is intended to be very very close to what DMDA would do

Re: [petsc-users] Fluid-Structure interaction with multiple DMPlex

Thibault Bridel-Bertomeu writes: > Hello everybody, > > So, let's say i have the mesh attached to this email that has 2 physical > surfaces and 5 physical curves. This gives me 2 strata in the "Cell Sets" > and 5 strata in the "Face Sets". > Would something like the following piece of code be

[petsc-users] PCSetCoordinates does not set coordinates of sub PC (fieldsplit) objects

Dear community, I am working on a block preconditioner, where one of the blocks uses HYPRE's AMS. As it requires the coordinates of the dofs, I have done so to the PC object. I expected the coordinates to be inherited down to the subblocks, is this not the case? (it seems so as I couldn't find a

[petsc-users] On PCSetCoordinates with Fieldsplit

Dear community,  I am working on a block preconditioner, where one of the blocks uses HYPRE's AMS. As it requires the coordinates of the dofs, I have done so to the PC object. I expected the coordinates to be inherited down to the subblocks, is this not the case? (it seems so as I couldn't

Re: [petsc-users] A problem with MatFDColoringSetFunction

A follow up: The compiler option '-Wno-bad-function-cast' did not work for c++. See message below: cc1plus: error: command line option '-Wno-bad-function-cast' is valid for C/ObjC but not for C++ [-Werror] Credit to David Andrs of INL, here is an alternative solution:

Re: [petsc-users] Fluid-Structure interaction with multiple DMPlex

Le mar. 11 janv. 2022 à 16:36, Jed Brown a écrit : > Thibault Bridel-Bertomeu writes: > > > Hello everybody, > > > > So, let's say i have the mesh attached to this email that has 2 physical > > surfaces and 5 physical curves. This gives me 2 strata in the "Cell Sets" > > and 5 strata in the

Re: [petsc-users] A problem with MatFDColoringSetFunction

Thanks for the alternative. @jed does this mean we need to do our casting of functions like this everywhere? > On Jan 11, 2022, at 12:11 PM, Zou, Ling wrote: > > A follow up: > > The compiler option '-Wno-bad-function-cast' did not work for c++. See > message below: > cc1plus:

Re: [petsc-users] PCSetCoordinates does not set coordinates of sub PC (fieldsplit) objects

Nicolas, For "simple" PCFIELDSPLIT it is possible to pass down the attached coordinate information. By simple I mean where the splitting is done by fields and not by general lists of IS (where one does not have enough information to know what the coordinates would mean to the subPCS).

[petsc-users] Loading DM binary data into 64-bit-integer PETSc

Dear PETSc community, I have PETSc binaries containing DM PetscScalars which were written with a PETSc configured without 64bit integers. Is it possible to load this data using a PETSc configured with 64bit integers? Thanks, Bastian

Re: [petsc-users] Loading DM binary data into 64-bit-integer PETSc

In general, no because the integer values inside the files will have different lengths. You can use the Python lib/petsc/bin/PetscBinaryIO.py or MATLAB share/petsc/matlab/*.m utilities to read the data from one format and save it in the other. Sorry for the inconvenience. Barry > On

Re: [petsc-users] A problem with MatFDColoringSetFunction

Barry Smith writes: > Thanks for the alternative. > > @jed does this mean we need to do our casting of functions like this > everywhere? Whenever our interfaces accept a function with a non-unique prototype, the interface should take void(*)(void) instead of PetscErrorCode(*)(void). I