landreman / sfincs

SFINCS: the Stellarator Fokker-Planck Iterative Neoclassical Conservative Solver
BSD 2-Clause "Simplified" License
22 stars 11 forks source link

Use of PetscScalar instead of PetscReal Types #3

Open lazersos opened 6 years ago

lazersos commented 6 years ago

The code is written using the PetscScalar type, but when linked to the complex version of the Petsc this type is of type COMPLEX making many of the logical statements syntactically incorrect. Also there are some issues with other intrinsic functions. The fix is to use the PetscReal type. However, this may introduce other issues. I'm going to test it out.

lazersos commented 6 years ago

Just a quick update is seems that for some reason, the diagnostic.F90 routines need a few arrays to be PetscScalar. The same is true in populateMatrix.F90.

lazersos commented 6 years ago

Compilation seems fine now. However, the PPPL build of PetSc was done without MUMPS so I need to get that corrected before I make more progress.

landreman commented 6 years ago

Sam- A complex petsc should not be used with sfincs. This causes the code to use 2x memory, and the code is already voracious for memory. -Matt

On Tue, Jan 2, 2018 at 4:55 AM, Samuel Lazerson notifications@github.com wrote:

Compilation seems fine now. However, the PPPL build of PetSc was done without MUMPS so I need to get that corrected before I make more progress.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/landreman/sfincs/issues/3#issuecomment-354732255, or mute the thread https://github.com/notifications/unsubscribe-auth/AE_Mgy4T2DzOHExpe1qlenkn3En5vCEKks5tGf0qgaJpZM4RQZzk .

--

Dr. Matt Landreman Associate Research Scientist Institute for Research in Electronics & Applied Physics University of Maryland 8223 Paint Branch Drive, College Park MD 20742, USA (+1) 651-366-9306 mattland@umd.edu

lazersos commented 6 years ago

@landreman Just spitballing here but in SFINCS many of the variables are declared as PetscScalar. When compiled and linked with PETSc complex this automatically changes the type to the Fortran COMPLEX type. This should result in twice the memory usage. If they were all typed as PetscReal then I would suspect this memory usage behavior would disappear. I could be wrong though. It depends on how casting is being handled internally. If PETSc was pure Fortran then at some level there must be differently defined subroutines for those with REAL, DOUBLE PRECISION, and COMPLEX input types. In the end the issue will be the interface to STELLOPT. When linking to GENE we link to complex PETSc and SLEPc. Either way I'll explore if there is a workaround. Of course first I have to get the IT group at PPPL to compile PETSc with MUMPS support. -Sam

amollen commented 4 years ago

@lazersos Noticed this old issue. Can I close it?

lazersos commented 4 years ago

@amollen Has SFINCS been updated to use the PetscReal?

amollen commented 4 years ago

@lazersos No it doesn't look like. I don't think anyone is working on it though. Maybe it is straightforward just changing all PetscScalar to PetscReal. Since the issue is more than two years old I thought it had just been left behind. But we can keep it open in case someone gets interested in doing it.