Re: [petsc-users] PETSc DS Auxiliary Variable Question

OK, I may as well just say that this is something that has never been quite clear to me. From what it looks, the auxiliary terms tend to denote material properties, or similar spatial varying terms. However, judging from the existence of both the 'constants' vector, as well as the derivative

Re: [petsc-users] PETSc DS Auxiliary Variable Question

Sounds like a lovely place to look again. sent from an overpriced pocket calculator On Tue, May 15, 2018, 17:21 Matthew Knepley wrote: > On Tue, May 15, 2018 at 8:11 PM, Robert Walker wrote: > >> Hello, >> >> I am writing a program using PETScDS along with

Re: [petsc-users] PETSc DS Auxiliary Variable Question

On Tue, May 15, 2018 at 8:11 PM, Robert Walker wrote: > Hello, > > I am writing a program using PETScDS along with PETScFE and PETScTS in a > similar vein to TS examples 45 - 48. I seek to use the auxiliary variables > accessed by the pointwise functions in a manner similar to

[petsc-users] PETSc DS Auxiliary Variable Question

Hello, I am writing a program using PETScDS along with PETScFE and PETScTS in a similar vein to TS examples 45 - 48. I seek to use the auxiliary variables accessed by the pointwise functions in a manner similar to how I understand that MOOSE handles auxiliary variables, that is that in the

Re: [petsc-users] Problems with DMDAVecGetArrayF90 + Intel

Satish Balay writes: >> typedef struct { char dummy; } F90Array1d; >> typedef struct { char dummy; } F90Array2d; >> typedef struct { char dummy; } F90Array3d; >> >> These are all distinct types. > > I'm not sure if they need to be distinct. Perhaps they are collapsible >

Re: [petsc-users] Problems with DMDAVecGetArrayF90 + Intel

On Tue, 15 May 2018, Jed Brown wrote: > Satish Balay writes: > > > On Tue, 15 May 2018, Jed Brown wrote: > > > >> > Your notation requires the following change > >> > > >> > PETSC_EXTERN void PETSC_STDCALL dmdavecgetarrayf901_(DM *da,Vec > >> > *v,F90Array1d

Re: [petsc-users] Problems with DMDAVecGetArrayF90 + Intel

Satish Balay writes: > On Tue, 15 May 2018, Jed Brown wrote: > >> > Your notation requires the following change >> > >> > PETSC_EXTERN void PETSC_STDCALL dmdavecgetarrayf901_(DM *da,Vec >> > *v,F90Array1d *a,PetscErrorCode *ierr PETSC_F90_2PTR_PROTO(ptrd)) >> > PETSC_EXTERN

Re: [petsc-users] Problems with DMDAVecGetArrayF90 + Intel

On Tue, 15 May 2018, Jed Brown wrote: > > Your notation requires the following change > > > > PETSC_EXTERN void PETSC_STDCALL dmdavecgetarrayf901_(DM *da,Vec > > *v,F90Array1d *a,PetscErrorCode *ierr PETSC_F90_2PTR_PROTO(ptrd)) > > PETSC_EXTERN PetscErrorCode > >

Re: [petsc-users] Problems with DMDAVecGetArrayF90 + Intel

Satish Balay writes: > On Tue, 15 May 2018, Jed Brown wrote: > >> Satish Balay writes: >> >> > On Tue, 15 May 2018, Jed Brown wrote: >> > >> >> Wow, how did this ever work with other compilers? >> >> >> >> To ensure everything gets fixed, I see we have >>

Re: [petsc-users] Problems with DMDAVecGetArrayF90 + Intel

On Tue, 15 May 2018, Jed Brown wrote: > Satish Balay writes: > > > On Tue, 15 May 2018, Jed Brown wrote: > > > >> Wow, how did this ever work with other compilers? > >> > >> To ensure everything gets fixed, I see we have > >> > >> #define F90Array3d void > >> > >> and

Re: [petsc-users] Problems with DMDAVecGetArrayF90 + Intel

Satish Balay writes: > On Tue, 15 May 2018, Jed Brown wrote: > >> Wow, how did this ever work with other compilers? >> >> To ensure everything gets fixed, I see we have >> >> #define F90Array3d void >> >> and then arguments are defined as >> >> F90Array3d *ptr >> >>

Re: [petsc-users] Problems with DMDAVecGetArrayF90 + Intel

On Tue, 15 May 2018, Jed Brown wrote: > Wow, how did this ever work with other compilers? > > To ensure everything gets fixed, I see we have > > #define F90Array3d void > > and then arguments are defined as > > F90Array3d *ptr > > We could make this type-safe by > > typedef struct {

Re: [petsc-users] Problems with DMDAVecGetArrayF90 + Intel

Looks like this issue got introduced with: http://bitbucket.org/petsc/petsc/commits/fcfd50eb5fb Satish On Tue, 15 May 2018, Jed Brown wrote: > Wow, how did this ever work with other compilers? > > To ensure everything gets fixed, I see we have > > #define F90Array3d void > > and then

Re: [petsc-users] Problems with DMDAVecGetArrayF90 + Intel

Wow, how did this ever work with other compilers? To ensure everything gets fixed, I see we have #define F90Array3d void and then arguments are defined as F90Array3d *ptr We could make this type-safe by typedef struct { void *ptr; } F90Array3d; and use this for arguments:

Re: [petsc-users] Problems with DMDAVecGetArrayF90 + Intel

> On Apr 10, 2018, at 5:40 PM, Satish Balay wrote: > > On Tue, 10 Apr 2018, Jeff Hammond wrote: > >> Can you try on a non-KNL host? It's a bug either way but I want to >> determine if KNL host is the issue. > > Breaks on 'E5-2695 v4' aswell (bebop.lcrc) with '-axcore-avx2'

Re: [petsc-users] monitoring the convergence of fieldsplit 0 and 1

Matt, Just a reminder. With petsc-3.8.4 the issue is still there. Chris dr. ir. Christiaan Klaij | Senior Researcher | Research & Development MARIN | T +31 317 49 33 44 | c.kl...@marin.nl | www.marin.nl