Re: [petsc-users] PETSC Matrix debugging

2024-04-01 Thread Shatanawi, Sawsan Muhammad via petsc-users 
Hello Barry and Matthew,

Yes MatView is what I was looking for. Thank you for your help.

Bests,
Sawsan

From: Barry Smith 
Sent: Monday, April 1, 2024 1:14 PM
To: Matthew Knepley 
Cc: Shatanawi, Sawsan Muhammad ; 
petsc-users@mcs.anl.gov 
Subject: Re: [petsc-users] PETSC Matrix debugging


[EXTERNAL EMAIL]

  Note, you can also run with the option -mat_view and it will print each 
matrix that gets assembled.

  Also in the debugger you can do call MatView(mat,0)



On Apr 1, 2024, at 2:18 PM, Matthew Knepley  wrote:

This Message Is From an External Sender
This message came from outside your organization.
On Mon, Apr 1, 2024 at 1:57 PM Shatanawi, Sawsan Muhammad via petsc-users 
mailto:petsc-users@mcs.anl.gov>> wrote:
This Message Is From an External Sender
This message came from outside your organization.

Hello everyone,

I hope this email finds you well.

Is there a way we can check how the matrix looks like after setting it.
I have tried debugging it with gdb- break points- and print statements, but it 
only gave me one value instead of a matrix.

Thank you in advance for your time and assistance.

I usually use MatView(), which can print to the screen. Is that what you want?

  Thanks,

 Matt

Best regards,

 Sawsan



--
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

https://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!dzUer79uIA6hcNT7qaG9AYDGyzDSYNgriB1CbMtHqSvf4Yo-IpKL7NBCWNtAUNcE4xbHLqQPsngdWk6kYcVImGviELhswASejA$

Re: [petsc-users] ex19: Segmentation Violation when run with MUMPS on MacOS (arm64)

2024-04-01 Thread Satish Balay via petsc-users 
On Mon, 1 Apr 2024, Zongze Yang wrote:

> Thank you for your update.
> 
> I found some links that suggest this issue is related to the Apple linker, 
> which is causing problems with Fortran linking.
> 
> 1. 
> https://urldefense.us/v3/__https://github.com/open-mpi/ompi/issues/12427__;!!G_uCfscf7eWS!bHY4uqpTfwl0jKopATQs3gw--TZSBmDp0Lb1gzDBeEu4ZB_zTph-jfw49yIr3jvPx0YEhQbk1PjYbGYVpjjms6Wb$
>  
> 2. 
> https://urldefense.us/v3/__https://x.com/science_dot/status/1768667417553547635?s=46__;!!G_uCfscf7eWS!bHY4uqpTfwl0jKopATQs3gw--TZSBmDp0Lb1gzDBeEu4ZB_zTph-jfw49yIr3jvPx0YEhQbk1PjYbGYVptASYXS2$
>   

https://urldefense.us/v3/__https://github.com/Homebrew/homebrew-core/issues/162714__;!!G_uCfscf7eWS!chekWa3R3JhHB1MVv33Oqj9fPFhbnx9sm7cm7Lk5-n7PHicsVkY0n7XoSkWmk259VLNjTzEus6xBpRL20MmLo1g$
  recommends "downgrade CLT (or xcode?) to 15.1"

Satish

Re: [petsc-users] PETSC Matrix debugging

2024-04-01 Thread Barry Smith 

  Note, you can also run with the option -mat_view and it will print each 
matrix that gets assembled.

  Also in the debugger you can do call MatView(mat,0)



> On Apr 1, 2024, at 2:18 PM, Matthew Knepley  wrote:
> 
> This Message Is From an External Sender
> This message came from outside your organization.
> On Mon, Apr 1, 2024 at 1:57 PM Shatanawi, Sawsan Muhammad via petsc-users 
> mailto:petsc-users@mcs.anl.gov>> wrote:
>> This Message Is From an External Sender
>> This message came from outside your organization.
>>  
>> Hello everyone,
>> 
>> I hope this email finds you well.
>> 
>> Is there a way we can check how the matrix looks like after setting it.
>> I have tried debugging it with gdb- break points- and print statements, but 
>> it only gave me one value instead of a matrix.
>>  
>> Thank you in advance for your time and assistance.
>> 
> I usually use MatView(), which can print to the screen. Is that what you want?
> 
>   Thanks,
> 
>  Matt 
>> Best regards,
>> 
>>  Sawsan
>> 
>> 
> 
> 
> -- 
> 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
> 
> https://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!bT1jdavVG8lGjxjhujAttmcaK9R1GFUxJtuFl1S2JK74c0mhrCwc2DkQippCFh8qwrk_9x5Dxjv-2H967RRgQPA$
>   
>

Re: [petsc-users] PETSC Matrix debugging

2024-04-01 Thread Matthew Knepley 
On Mon, Apr 1, 2024 at 1:57 PM Shatanawi, Sawsan Muhammad via petsc-users <
petsc-users@mcs.anl.gov> wrote:

> Hello everyone, I hope this email finds you well. Is there a way we can
> check how the matrix looks like after setting it. I have tried debugging it
> with gdb- break points- and print statements, but it only gave me one value
> instead of a matrix.
> ZjQcmQRYFpfptBannerStart
> This Message Is From an External Sender
> This message came from outside your organization.
>
> ZjQcmQRYFpfptBannerEnd
> Hello everyone,
>
> I hope this email finds you well.
>
> Is there a way we can check how the matrix looks like after setting it.
> I have tried debugging it with gdb- break points- and print statements,
> but it only gave me one value instead of a matrix.
>
> Thank you in advance for your time and assistance.
>
> I usually use MatView(), which can print to the screen. Is that what you
want?

  Thanks,

 Matt

> Best regards,
>
>  Sawsan
>
>

-- 
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

https://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!cFl9o86vmX7ZWINcjhpIy1gzc938wF-1bgwtrPGwm8zQQ71WUgVstEpSos7o1OWqfmTup5bgaekGgfUuG7aF$

[petsc-users] PETSC Matrix debugging

2024-04-01 Thread Shatanawi, Sawsan Muhammad via petsc-users 
Hello everyone,

I hope this email finds you well.

Is there a way we can check how the matrix looks like after setting it.
I have tried debugging it with gdb- break points- and print statements, but it 
only gave me one value instead of a matrix.

Thank you in advance for your time and assistance.

Best regards,

 Sawsan

Re: [petsc-users] ex19: Segmentation Violation when run with MUMPS on MacOS (arm64)

2024-04-01 Thread Zongze Yang 
Thank you for your update.

I found some links that suggest this issue is related to the Apple linker, 
which is causing problems with Fortran linking.

1. 
https://urldefense.us/v3/__https://github.com/open-mpi/ompi/issues/12427__;!!G_uCfscf7eWS!bHY4uqpTfwl0jKopATQs3gw--TZSBmDp0Lb1gzDBeEu4ZB_zTph-jfw49yIr3jvPx0YEhQbk1PjYbGYVpjjms6Wb$
 
2. 
https://urldefense.us/v3/__https://x.com/science_dot/status/1768667417553547635?s=46__;!!G_uCfscf7eWS!bHY4uqpTfwl0jKopATQs3gw--TZSBmDp0Lb1gzDBeEu4ZB_zTph-jfw49yIr3jvPx0YEhQbk1PjYbGYVptASYXS2$
  

Best wishes,
Zongze

> On 2 Apr 2024, at 01:15, Satish Balay  wrote:
> 
> On Mon, 1 Apr 2024, Zongze Yang wrote:
> 
>> 
>> I noticed this in the config.log of OpenMPI:
>> ```
>> configure:30230: checking to see if mpifort compiler needs additional linker 
>> flags
>> configure:30247: gfortran -o conftest -fPIC -ffree-line-length-none 
>> -ffree-line-length-0 -Wno-lto-type-mismatch -g -O0 -fallow-argument-mismatch 
>>  -Wl,-flat_namespace -Wl,-commons,use_dylibs  conftest.f90  >&5
>> ld: warning: -commons use_dylibs is no longer supported, using error 
>> treatment instead
>> configure:30247: $? = 0
>> configure:30299: result: -Wl,-commons,use_dylibs
>> ```
>> So, I find it odd that this flag isn't picked up on your platform, as it 
>> only checked the exit value.
> 
> I get:
> 
> configure:30247: gfortran -o conftest -fPIC -ffree-line-length-none 
> -ffree-line-length-0 -Wno-lto-type-mismatch -g -O0 -fallow-argument-mismatch  
> -Wl,-flat_namespace -Wl,-commons,use_dylibs  conftest.f90  >&5
> ld: unknown options: -commons 
> collect2: error: ld returned 1 exit status
> configure:30247: $? = 1
> configure: failed program was:
> | program test
> | integer :: i
> | end program
> configure:30299: result: none
> 
> Note, I have and older xcode-15/CLT version:
> 
> petsc@npro ~ % clang --version
> Apple clang version 15.0.0 (clang-1500.1.0.2.5)
> Target: arm64-apple-darwin23.3.0
> Thread model: posix
> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
> 
> Satish

Re: [petsc-users] ex19: Segmentation Violation when run with MUMPS on MacOS (arm64)

2024-04-01 Thread Satish Balay via petsc-users 
On Mon, 1 Apr 2024, Zongze Yang wrote:

> 
> I noticed this in the config.log of OpenMPI:
> ```
> configure:30230: checking to see if mpifort compiler needs additional linker 
> flags
> configure:30247: gfortran -o conftest -fPIC -ffree-line-length-none 
> -ffree-line-length-0 -Wno-lto-type-mismatch -g -O0 -fallow-argument-mismatch  
> -Wl,-flat_namespace -Wl,-commons,use_dylibs  conftest.f90  >&5
> ld: warning: -commons use_dylibs is no longer supported, using error 
> treatment instead
> configure:30247: $? = 0
> configure:30299: result: -Wl,-commons,use_dylibs
> ```
> So, I find it odd that this flag isn't picked up on your platform, as it only 
> checked the exit value.

I get:

configure:30247: gfortran -o conftest -fPIC -ffree-line-length-none 
-ffree-line-length-0 -Wno-lto-type-mismatch -g -O0 -fallow-argument-mismatch  
-Wl,-flat_namespace -Wl,-commons,use_dylibs  conftest.f90  >&5
ld: unknown options: -commons 
collect2: error: ld returned 1 exit status
configure:30247: $? = 1
configure: failed program was:
| program test
| integer :: i
| end program
configure:30299: result: none

Note, I have and older xcode-15/CLT version:

petsc@npro ~ % clang --version
Apple clang version 15.0.0 (clang-1500.1.0.2.5)
Target: arm64-apple-darwin23.3.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Satish

Re: [petsc-users] ex19: Segmentation Violation when run with MUMPS on MacOS (arm64)

2024-04-01 Thread Zongze Yang 




 > On 1 Apr 2024, at 23: 38, Satish Balay  wrote: > > On Sun, 31 Mar 2024, Zongze Yang wrote: >>> --- >>> petsc@ npro petsc % ./configure --download-bison --download-chaco --download-ctetgen




ZjQcmQRYFpfptBannerStart




  

  
	This Message Is From an External Sender
  
  
This message came from outside your organization.
  



 
  


ZjQcmQRYFpfptBannerEnd






> On 1 Apr 2024, at 23:38, Satish Balay  wrote:
> 
> On Sun, 31 Mar 2024, Zongze Yang wrote:
>>> ---
>>> petsc@npro petsc % ./configure --download-bison --download-chaco --download-ctetgen --download-eigen --download-fftw --download-hdf5 --download-hpddm --download-hwloc --download-hypre --download-libpng --download-metis --download-mmg --download-mumps --download-netcdf --download-openblas
>> --download-openblas-make-options="'USE_THREAD=0 USE_LOCKING=1 USE_OPENMP=0'" --download-p4est --download-parmmg --download-pnetcdf --download-pragmatic --download-ptscotch --download-scalapack --download-slepc --download-suitesparse --download-superlu_dist --download-tetgen --download-tri
>> angle --with-c2html=0 --with-debugging=1 --with-fortran-bindings=0 --with-shared-libraries=1 --with-x=0 --with-zlib --download-openmpi=https://urldefense.us/v3/__https://download.open-mpi.org/release/open-mpi/v5.0/openmpi-5.0.3rc1.tar.bz2__;!!G_uCfscf7eWS!aCLPUhLfLFG5UwNlUWgGGhXZlw905gJwDd
>>AryIrltDIXJcdmOP6Is44FzBVrY5ndwzmIqMhI515mnNjTuHoR-tzq$ --download-pastix=https://urldefense.us/v3/__https://web.cels.anl.gov/projects/petsc/download/externalpackages/pastix_5.2.3-p1.tar.bz2__;!!G_uCfscf7eWS!aCLPUhLfLFG5UwNlUWgGGhXZlw905gJwDdAryIrltDIXJcdmOP6Is44FzBVrY5ndwzmIqMhI515mnNjTuA
>>fJ49xl$ && make && make check
>> 
>> There's an error encountered during configuration with the above options:
>> ```
>> TESTING: FortranMPICheck from config.packages.MPI(config/BuildSystem/config/packages/MPI.py:676)
>> *
>>   UNABLE to CONFIGURE with GIVEN OPTIONS (see configure.log for details):
>> -
>>   Fortran error! mpi_init() could not be located!
>> *
>> ```
>> Please refer to the attached file for further information.
> 
> So I'm getting:
> 
>>> 
> *** Fortran compiler
> checking whether the compiler supports GNU Fortran... yes
> checking whether gfortran accepts -g... yes
> checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
> checking the name lister (/usr/bin/nm -B) interface... BSD nm
> checking whether ln -s works... yes
> checking if Fortran compiler works... yes
> checking for extra arguments to build a shared library... impossible -- -static
> checking for gfortran warnings flags... none
> checking for Fortran flag to compile .f files... none
> checking for Fortran flag to compile .f90 files... none
> checking if Fortran compilers preprocess .F90 files without additional flag... yes
> checking to see if Fortran compilers need additional linker flags... -Wl,-flat_namespace
> checking  external symbol convention... single underscore
> checking if C and Fortran are link compatible... yes
> checking to see if Fortran compiler likes the C++ exception flags... skipped (no C++ exceptions flags)
> checking to see if mpifort compiler needs additional linker flags... none
> 
> 
> However you are getting:
> 
> 
> *** Fortran compiler
> checking whether the compiler supports GNU Fortran... yes
> checking whether gfortran accepts -g... yes
> checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
> checking the name lister (/usr/bin/nm -B) interface... BSD nm
> checking whether ln -s works... yes
> checking if Fortran compiler works... yes
> checking for extra arguments to build a shared library... impossible -- -static
> checking for gfortran warnings flags... none
> checking for Fortran flag to compile .f files... none
> checking for Fortran flag to compile .f90 files... none
> checking if Fortran compilers preprocess .F90 files without additional flag... yes
> checking to see if Fortran compilers need additional linker flags... -Wl,-flat_namespace
> checking  external symbol convention... single underscore
> checking if C and Fortran are link compatible... yes
> checking to see if Fortran compiler likes the C++ exception flags... skipped (no C++ exceptions flags)
> checking to see if mpifort compiler needs additional linker flags... -Wl,-commons,use_dylibs
> 
> 
> So gfortran [or ld from this newer xcode?] is behaving differently - and openmpi is picking up and using this broken/unsupported option - and likely triggering subsequent errors.

I noticed this in the config.log of OpenMPI:
```
configure:30230: checking to see if mpifort compiler needs additional linker flags
configure:30247: gfortran -o conftest

Re: [petsc-users] Error loading data coming from a .hdf5 file into a DMSwarm

2024-04-01 Thread MIGUEL MOLINOS PEREZ 
I see. Thank you for the feedback Matthew!

Thanks,
Miguel

On 1 Apr 2024, at 18:32, Matthew Knepley  wrote:

On Mon, Apr 1, 2024 at 11:13 AM MIGUEL MOLINOS PEREZ 
mailto:mmoli...@us.es>> wrote:
Dear Matthew,

Thank you for your suggestion. I tried to update the vector with the 
information coming from the hdf5 file inside the main function. Then I print 
the vector two times (see the lines below), the first time it has the correct 
data. However, the second time, it has the same values like I never updated it 
with VecLoad.

It is an alternative way of initialise a vector coming from DMSWarm with 
previously stored information (keeping the parallel structure)?

Oh, you cannot use the Swarm vectors for VecLoad(). They are just a view into 
the particle data, and that view is destroyed on restore. Swarm data is stored 
in a particle-like data structure, not in Vecs. If you want to load this Vec, 
you have to duplicate exactly as you did. This interface is likely to change in 
the next year to make this problem go away.

  Thanks,

Matt

Miguel

//! Load Hdf5 viewer
PetscViewer viewer_hdf5;
REQUIRE_NOTHROW(PetscViewerHDF5Open(MPI_COMM_WORLD, Output_hdf5_file,
FILE_MODE_READ, _hdf5));
REQUIRE_NOTHROW(PetscViewerHDF5PushTimestepping(viewer_hdf5));

//! Load the vector and fill it with the information from the .hdf5 file
Vec stdv_q;
REQUIRE_NOTHROW(DMSwarmCreateGlobalVectorFromField(
Simulation.atomistic_data, "stdv-q", _q));

REQUIRE_NOTHROW(PetscViewerHDF5PushGroup(viewer_hdf5, "/particle_fields"));
REQUIRE_NOTHROW(VecLoad(stdv_q, viewer_hdf5));
REQUIRE_NOTHROW(VecView(stdv_q, PETSC_VIEWER_STDOUT_WORLD));
REQUIRE_NOTHROW(PetscViewerHDF5PopGroup(viewer_hdf5));

REQUIRE_NOTHROW(DMSwarmDestroyGlobalVectorFromField(
Simulation.atomistic_data, "stdv-q", _q));

//! Destoy HDF5 context
REQUIRE_NOTHROW(PetscViewerDestroy(_hdf5));

//! Load the vector again and print
REQUIRE_NOTHROW(DMSwarmCreateGlobalVectorFromField(
Simulation.atomistic_data, "stdv-q", _q));

REQUIRE_NOTHROW(VecView(stdv_q, PETSC_VIEWER_STDOUT_WORLD));

REQUIRE_NOTHROW(DMSwarmDestroyGlobalVectorFromField(
Simulation.atomistic_data, "stdv-q", _q));

Best,
Miguel

Miguel Molinos
Investigador postdoctoral
Juan de la Cierva
Dpto. Mecánica de Medios Continuos y Teoría de Estructuras - ETSI
Universidad de Sevilla
Camino de los descubrimientos, s/n
41092 Sevilla







https://urldefense.us/v3/__http://www.us.es__;!!G_uCfscf7eWS!Z_MoZ7Bj4eyIXKal80C357h4aO105lFAgZwG6a6xZwNKsKVTzZ4HfUspESkt1TKg2MOv5bbWwmDB8Gsd-nJ2ng$
 

Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, 
contiene información de carácter confidencial exclusivamente dirigida a su 
destinatario o destinatarios. Si no es UD. el destinatario del mensaje, le 
ruego lo destruya sin hacer copia digital o física, comunicando al emisor por 
esta misma vía la recepción del presente mensaje. Gracias




On 1 Apr 2024, at 16:28, Matthew Knepley 
mailto:knep...@gmail.com>> wrote:

>From the description, my guess is that this is pointer confusion. The vector 
>inside the function is different from the vector outside the function.




--
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

https://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!Z_MoZ7Bj4eyIXKal80C357h4aO105lFAgZwG6a6xZwNKsKVTzZ4HfUspESkt1TKg2MOv5bbWwmDB8Gs0StP1_g$

Re: [petsc-users] Error loading data coming from a .hdf5 file into a DMSwarm

2024-04-01 Thread Matthew Knepley 
On Mon, Apr 1, 2024 at 11:13 AM MIGUEL MOLINOS PEREZ  wrote:

> Dear Matthew,
>
> Thank you for your suggestion. I tried to update the vector with the
> information coming from the hdf5 file inside the main function. Then I
> print the vector two times (see the lines below), the first time it has the
> correct data. However, the second time, it has the same values like I never
> updated it with VecLoad.
>
> It is an alternative way of initialise a vector coming from DMSWarm with
> previously stored information (keeping the parallel structure)?
>

Oh, you cannot use the Swarm vectors for VecLoad(). They are just a view
into the particle data, and that view is destroyed on restore. Swarm data
is stored in a particle-like data structure, not in Vecs. If you want to
load this Vec, you have to duplicate exactly as you did. This interface is
likely to change in the next year to make this problem go away.

  Thanks,

Matt


> Miguel
>
> //! Load Hdf5 viewer
> PetscViewer viewer_hdf5;
> REQUIRE_NOTHROW(PetscViewerHDF5Open(MPI_COMM_WORLD, Output_hdf5_file,
> FILE_MODE_READ, _hdf5));
> REQUIRE_NOTHROW(PetscViewerHDF5PushTimestepping(viewer_hdf5));
>
> //! Load the vector and fill it with the information from the .hdf5 file
> Vec stdv_q;
> REQUIRE_NOTHROW(DMSwarmCreateGlobalVectorFromField(
> Simulation.atomistic_data, "stdv-q", _q));
>
> REQUIRE_NOTHROW(PetscViewerHDF5PushGroup(viewer_hdf5, "/particle_fields"
> ));
> REQUIRE_NOTHROW(VecLoad(stdv_q, viewer_hdf5));
> REQUIRE_NOTHROW(VecView(stdv_q, PETSC_VIEWER_STDOUT_WORLD));
> REQUIRE_NOTHROW(PetscViewerHDF5PopGroup(viewer_hdf5));
>
> REQUIRE_NOTHROW(DMSwarmDestroyGlobalVectorFromField(
> Simulation.atomistic_data, "stdv-q", _q));
>
> //! Destoy HDF5 context
> REQUIRE_NOTHROW(PetscViewerDestroy(_hdf5));
>
> //! Load the vector again and print
> REQUIRE_NOTHROW(DMSwarmCreateGlobalVectorFromField(
> Simulation.atomistic_data, "stdv-q", _q));
>
> REQUIRE_NOTHROW(VecView(stdv_q, PETSC_VIEWER_STDOUT_WORLD));
>
> REQUIRE_NOTHROW(DMSwarmDestroyGlobalVectorFromField(
> Simulation.atomistic_data, "stdv-q", _q));
>
> Best,
> Miguel
>
> Miguel Molinos
> Investigador postdoctoral
> Juan de la Cierva
> Dpto. Mecánica de Medios Continuos y Teoría de Estructuras - ETSI
> Universidad de Sevilla
> Camino de los descubrimientos, s/n
> 41092 Sevilla
>
>
> [image: us_logo.jpg]
>
>
>
>
> https://urldefense.us/v3/__http://www.us.es__;!!G_uCfscf7eWS!YcVqv_PA_UdFsx4fZHfzMMaZZ7auMp-poE49ThdEDk0fT7DAXF6-0fOpeWMEOJcrVL5grSHp-QCF8PdvRl51$
>  
> Este correo electrónico y, en su caso, cualquier fichero anexo al
> mismo, contiene información de carácter confidencial exclusivamente
> dirigida a su destinatario o destinatarios. Si no es UD. el
> destinatario del mensaje, le ruego lo destruya sin hacer copia digital o
> física, comunicando al emisor por esta misma vía la recepción del presente
> mensaje. Gracias
>
>
>
>
> On 1 Apr 2024, at 16:28, Matthew Knepley  wrote:
>
> From the description, my guess is that this is pointer confusion. The
> vector inside the function is different from the vector outside the
> function.
>
>
>

-- 
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

https://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!YcVqv_PA_UdFsx4fZHfzMMaZZ7auMp-poE49ThdEDk0fT7DAXF6-0fOpeWMEOJcrVL5grSHp-QCF8EnZVeTC$

Re: [petsc-users] Error loading data coming from a .hdf5 file into a DMSwarm

2024-04-01 Thread MIGUEL MOLINOS PEREZ 
Dear Matthew,

I came up with a workaround for the problem. I duplicate the vector and use the 
duplicated copy to read the information from the hdf5 file. Then I swap both 
vectors and delete the copy. If I invoke VecView outside of the function, the 
value has been modified properly. However, this solution seems a little bit 
“ugly”. I share it just in case someone is facing a similar problem or it can 
help to understand what is going wrong with my previous implementation.

Best,
Miguel

Vec stdv_q;
PetscCall(DMSwarmCreateGlobalVectorFromField(Simulation->atomistic_data,
"stdv-q", _q));

Vec stdv_q_hdf5;
PetscCall(VecDuplicate(stdv_q, _q_hdf5));
PetscCall(PetscObjectSetName((PetscObject)stdv_q_hdf5,
"DMSwarmSharedField_stdv-q"));

PetscCall(VecLoad(stdv_q_hdf5, viewer_hdf5));

PetscCall(VecSwap(stdv_q, stdv_q_hdf5));
PetscCall(VecDestroy(_q_hdf5));

PetscCall(DMSwarmDestroyGlobalVectorFromField(Simulation->atomistic_data,
"stdv-q", _q));

On 1 Apr 2024, at 17:13, Miguel Molinos  wrote:

Dear Matthew,

Thank you for your suggestion. I tried to update the vector with the 
information coming from the hdf5 file inside the main function. Then I print 
the vector two times (see the lines below), the first time it has the correct 
data. However, the second time, it has the same values like I never updated it 
with VecLoad.

It is an alternative way of initialise a vector coming from DMSWarm with 
previously stored information (keeping the parallel structure)?

Miguel

//! Load Hdf5 viewer
PetscViewer viewer_hdf5;
REQUIRE_NOTHROW(PetscViewerHDF5Open(MPI_COMM_WORLD, Output_hdf5_file,
FILE_MODE_READ, _hdf5));
REQUIRE_NOTHROW(PetscViewerHDF5PushTimestepping(viewer_hdf5));

//! Load the vector and fill it with the information from the .hdf5 file
Vec stdv_q;
REQUIRE_NOTHROW(DMSwarmCreateGlobalVectorFromField(
Simulation.atomistic_data, "stdv-q", _q));

REQUIRE_NOTHROW(PetscViewerHDF5PushGroup(viewer_hdf5, "/particle_fields"));
REQUIRE_NOTHROW(VecLoad(stdv_q, viewer_hdf5));
REQUIRE_NOTHROW(VecView(stdv_q, PETSC_VIEWER_STDOUT_WORLD));
REQUIRE_NOTHROW(PetscViewerHDF5PopGroup(viewer_hdf5));

REQUIRE_NOTHROW(DMSwarmDestroyGlobalVectorFromField(
Simulation.atomistic_data, "stdv-q", _q));

//! Destoy HDF5 context
REQUIRE_NOTHROW(PetscViewerDestroy(_hdf5));

//! Load the vector again and print
REQUIRE_NOTHROW(DMSwarmCreateGlobalVectorFromField(
Simulation.atomistic_data, "stdv-q", _q));

REQUIRE_NOTHROW(VecView(stdv_q, PETSC_VIEWER_STDOUT_WORLD));

REQUIRE_NOTHROW(DMSwarmDestroyGlobalVectorFromField(
Simulation.atomistic_data, "stdv-q", _q));

Best,
Miguel

Miguel Molinos
Investigador postdoctoral
Juan de la Cierva
Dpto. Mecánica de Medios Continuos y Teoría de Estructuras - ETSI
Universidad de Sevilla
Camino de los descubrimientos, s/n
41092 Sevilla







https://urldefense.us/v3/__http://www.us.es__;!!G_uCfscf7eWS!dcgV4Ks7of5UCrBcwXoQzq1ZP06FAF8IaHAwnyo5mL5uiBMiKj2mxO7W6odOpn8LRgla6ehj-QCjHK2MbBf_1Q$
 
Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, 
contiene información de carácter confidencial exclusivamente dirigida a su 
destinatario o destinatarios. Si no es UD. el destinatario del mensaje, le 
ruego lo destruya sin hacer copia digital o física, comunicando al emisor por 
esta misma vía la recepción del presente mensaje. Gracias




On 1 Apr 2024, at 16:28, Matthew Knepley  wrote:

>From the description, my guess is that this is pointer confusion. The vector 
>inside the function is different from the vector outside the function.

Re: [petsc-users] ex19: Segmentation Violation when run with MUMPS on MacOS (arm64)

2024-04-01 Thread Satish Balay via petsc-users 
On Sun, 31 Mar 2024, Zongze Yang wrote:
> > ---
> > petsc@npro petsc % ./configure --download-bison --download-chaco 
> > --download-ctetgen --download-eigen --download-fftw --download-hdf5 
> > --download-hpddm --download-hwloc --download-hypre --download-libpng 
> > --download-metis --download-mmg --download-mumps --download-netcdf 
> > --download-openblas
>  --download-openblas-make-options="'USE_THREAD=0 USE_LOCKING=1 USE_OPENMP=0'" 
> --download-p4est --download-parmmg --download-pnetcdf --download-pragmatic 
> --download-ptscotch --download-scalapack --download-slepc 
> --download-suitesparse --download-superlu_dist --download-tetgen 
> --download-tri
> angle --with-c2html=0 --with-debugging=1 --with-fortran-bindings=0 
> --with-shared-libraries=1 --with-x=0 --with-zlib 
> --download-openmpi=https://urldefense.us/v3/__https://download.open-mpi.org/release/open-mpi/v5.0/openmpi-5.0.3rc1.tar.bz2__;!!G_uCfscf7eWS!aCLPUhLfLFG5UwNlUWgGGhXZlw905gJwDd
> AryIrltDIXJcdmOP6Is44FzBVrY5ndwzmIqMhI515mnNjTuHoR-tzq$ 
> --download-pastix=https://urldefense.us/v3/__https://web.cels.anl.gov/projects/petsc/download/externalpackages/pastix_5.2.3-p1.tar.bz2__;!!G_uCfscf7eWS!aCLPUhLfLFG5UwNlUWgGGhXZlw905gJwDdAryIrltDIXJcdmOP6Is44FzBVrY5ndwzmIqMhI515mnNjTuA
> fJ49xl$ && make && make check
> 
> There's an error encountered during configuration with the above options:
> ```
> TESTING: FortranMPICheck from 
> config.packages.MPI(config/BuildSystem/config/packages/MPI.py:676)
> *
>UNABLE to CONFIGURE with GIVEN OPTIONS (see configure.log for 
> details):
> -
>Fortran error! mpi_init() could not be located!
> *
> ```
> Please refer to the attached file for further information.

So I'm getting:

>>
*** Fortran compiler
checking whether the compiler supports GNU Fortran... yes
checking whether gfortran accepts -g... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking if Fortran compiler works... yes
checking for extra arguments to build a shared library... impossible -- -static
checking for gfortran warnings flags... none
checking for Fortran flag to compile .f files... none
checking for Fortran flag to compile .f90 files... none
checking if Fortran compilers preprocess .F90 files without additional flag... 
yes
checking to see if Fortran compilers need additional linker flags... 
-Wl,-flat_namespace
checking  external symbol convention... single underscore
checking if C and Fortran are link compatible... yes
checking to see if Fortran compiler likes the C++ exception flags... skipped 
(no C++ exceptions flags)
checking to see if mpifort compiler needs additional linker flags... none


However you are getting:


*** Fortran compiler
checking whether the compiler supports GNU Fortran... yes
checking whether gfortran accepts -g... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking if Fortran compiler works... yes
checking for extra arguments to build a shared library... impossible -- -static
checking for gfortran warnings flags... none
checking for Fortran flag to compile .f files... none
checking for Fortran flag to compile .f90 files... none
checking if Fortran compilers preprocess .F90 files without additional flag... 
yes
checking to see if Fortran compilers need additional linker flags... 
-Wl,-flat_namespace
checking  external symbol convention... single underscore
checking if C and Fortran are link compatible... yes
checking to see if Fortran compiler likes the C++ exception flags... skipped 
(no C++ exceptions flags)
checking to see if mpifort compiler needs additional linker flags... 
-Wl,-commons,use_dylibs


So gfortran [or ld from this newer xcode?] is behaving differently - and 
openmpi is picking up and using this broken/unsupported option - and likely 
triggering subsequent errors.

>>>
ld: warning: -commons use_dylibs is no longer supported, using error treatment 
instead
ld: common symbol '_mpi_fortran_argv_null_' from 
'/private/var/folders/tf/v4zjvtw12yb3tszk813gmnvwgn/T/petsc-xyn64q55/config.libraries/conftest.o'
 conflicts with definition from dylib '_mpi_fortran_argv_null_' from 
'/Users/zzyang/workspace/repos/petsc/arch-darwin-c-debug/lib/libmpi_usempif08.40.dylib'
<<<

Or perhaps openmpi configure is affected by this new warning that this newer 
xcode spews
>>>
ld: warning: duplicate -rpath 
'/opt/homebrew/Cellar/gcc/13.2.0/lib/gcc/current/gcc' ignored
<<<

I'm not sure what to suggest here [other than using Linux - and

Re: [petsc-users] Error loading data coming from a .hdf5 file into a DMSwarm

2024-04-01 Thread MIGUEL MOLINOS PEREZ 
Dear Matthew,

Thank you for your suggestion. I tried to update the vector with the 
information coming from the hdf5 file inside the main function. Then I print 
the vector two times (see the lines below), the first time it has the correct 
data. However, the second time, it has the same values like I never updated it 
with VecLoad.

It is an alternative way of initialise a vector coming from DMSWarm with 
previously stored information (keeping the parallel structure)?

Miguel

//! Load Hdf5 viewer
PetscViewer viewer_hdf5;
REQUIRE_NOTHROW(PetscViewerHDF5Open(MPI_COMM_WORLD, Output_hdf5_file,
FILE_MODE_READ, _hdf5));
REQUIRE_NOTHROW(PetscViewerHDF5PushTimestepping(viewer_hdf5));

//! Load the vector and fill it with the information from the .hdf5 file
Vec stdv_q;
REQUIRE_NOTHROW(DMSwarmCreateGlobalVectorFromField(
Simulation.atomistic_data, "stdv-q", _q));

REQUIRE_NOTHROW(PetscViewerHDF5PushGroup(viewer_hdf5, "/particle_fields"));
REQUIRE_NOTHROW(VecLoad(stdv_q, viewer_hdf5));
REQUIRE_NOTHROW(VecView(stdv_q, PETSC_VIEWER_STDOUT_WORLD));
REQUIRE_NOTHROW(PetscViewerHDF5PopGroup(viewer_hdf5));

REQUIRE_NOTHROW(DMSwarmDestroyGlobalVectorFromField(
Simulation.atomistic_data, "stdv-q", _q));

//! Destoy HDF5 context
REQUIRE_NOTHROW(PetscViewerDestroy(_hdf5));

//! Load the vector again and print
REQUIRE_NOTHROW(DMSwarmCreateGlobalVectorFromField(
Simulation.atomistic_data, "stdv-q", _q));

REQUIRE_NOTHROW(VecView(stdv_q, PETSC_VIEWER_STDOUT_WORLD));

REQUIRE_NOTHROW(DMSwarmDestroyGlobalVectorFromField(
Simulation.atomistic_data, "stdv-q", _q));

Best,
Miguel

Miguel Molinos
Investigador postdoctoral
Juan de la Cierva
Dpto. Mecánica de Medios Continuos y Teoría de Estructuras - ETSI
Universidad de Sevilla
Camino de los descubrimientos, s/n
41092 Sevilla


[us_logo.jpg]




https://urldefense.us/v3/__http://www.us.es__;!!G_uCfscf7eWS!cBA1ckF1ChOi-Bgd9vd_TbaJmDZbonuQUNk2GOtfDnlYlIyTsO0mIZDspS-H1SopQFNhXZr5udHSOKQPUNQ-Xw$
 
Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, 
contiene información de carácter confidencial exclusivamente dirigida a su 
destinatario o destinatarios. Si no es UD. el destinatario del mensaje, le 
ruego lo destruya sin hacer copia digital o física, comunicando al emisor por 
esta misma vía la recepción del presente mensaje. Gracias




On 1 Apr 2024, at 16:28, Matthew Knepley  wrote:

>From the description, my guess is that this is pointer confusion. The vector 
>inside the function is different from the vector outside the function.

Re: [petsc-users] Error loading data coming from a .hdf5 file into a DMSwarm

2024-04-01 Thread Matthew Knepley 
On Sun, Mar 31, 2024 at 4:08 PM MIGUEL MOLINOS PEREZ  wrote:

> Dear all, I am writing a function which store datasets (Vectors) coming
> from a DMSwarm structure into a hdf5 file. This step is done nicely
> write_function(){ PetscViewerHDF5Open(…) PetscViewerHDF5PushTimestepping(…)
> DMSwarmCreateGlobalVectorFromField(…)
> ZjQcmQRYFpfptBannerStart
> This Message Is From an External Sender
> This message came from outside your organization.
>
> ZjQcmQRYFpfptBannerEnd
> Dear all,
>
> I am writing a function which store datasets (Vectors) coming from a DMSwarm
> structure into a hdf5 file. This step is done nicely
>
> write_function(){
> PetscViewerHDF5Open(…)
> PetscViewerHDF5PushTimestepping(…)
> DMSwarmCreateGlobalVectorFromField(…)
> VecLoad(…)
> DMSwarmDestroyGlobalVectorFromField(…)
> }
>
> The resulting hdf5 file looks good after an inspection using python’s
> library h5py.
>
> However, I am finding difficulties when I try to use this .hdf5 file as a
> fresh start for my application. The target field is not properly updated
> when I try to load the stored data (it keeps the default one).
>
> read_function(){
> …
> PetscViewerHDF5Open(…)
> PetscViewerHDF5PushTimestepping(…)
> DMSwarmCreateGlobalVectorFromField(…)
> VecLoad(… )
> DMSwarmDestroyGlobalVectorFromField(…)
> ...
> }
>
> The puzzling part is: if I print the “updated” vector inside of
> read_function() using VecView after VecLoad, the vector seem to hold the
> updated values. However, If I print the field in the main function after
> the call to read_function(), the field remains the same it was before
> calling to read_function() and I do not get any erro message.
>
> It is there something wrong with the logic of my programing? Maybe I am
> missing something.
>

>From the description, my guess is that this is pointer confusion. The
vector inside the function is different from the vector outside the
function.

  Thanks,

Matt


> Thank you in advance.
>
> Best regards,
> Miguel
>
> Miguel Molinos
> Investigador postdoctoral
> Juan de la Cierva
> Dpto. Mecánica de Medios Continuos y Teoría de Estructuras - ETSI
> Universidad de Sevilla
> Camino de los descubrimientos, s/n
> 41092 Sevilla
>
>
> [image: us_logo.jpg]
>
>
>
>
>
> https://urldefense.us/v3/__http://www.us.es__;!!G_uCfscf7eWS!YnltLCiNPOvMtX9m3CBEtxQ-FLDRM3Ef6ZAOt3huF3xEquvYmdHNozTGvZpnCoX8m3gZ_6W9SXKOxFP20r74$
>  
> 
> Este correo electrónico y, en su caso, cualquier fichero anexo al
> mismo, contiene información de carácter confidencial exclusivamente
> dirigida a su destinatario o destinatarios. Si no es UD. el
> destinatario del mensaje, le ruego lo destruya sin hacer copia digital o
> física, comunicando al emisor por esta misma vía la recepción del presente
> mensaje. Gracias
>
>

-- 
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

https://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!YnltLCiNPOvMtX9m3CBEtxQ-FLDRM3Ef6ZAOt3huF3xEquvYmdHNozTGvZpnCoX8m3gZ_6W9SXKOxFq8o9DM$