[sundials-users] KINSOL latest version installation

[Debadutta Prusty]

Hello users,

I am trying to install kinsol-6.2.0 but with little luck and the reason has to do with the computer not being able to locate ccmake. To be specific, when I enter the command " ccmake ../kinsol-6.2.0/", it returns "The program 'ccmake' is currently not installed. You can install it by typing:
sudo apt install cmake-curses-gui". Now the problem with the above installation procedure is that it installs cmake 3.5.0 while the current version of kinsol requires cmake to be above 3.12. I already have 3.17.3 installed on my computer but it's not being recognized by kinsol. Has anyone faced this or a similar issue before?

Thanks,

Debadutta Prusty

 

---

To unsubscribe from the SUNDIALS-USERS list: write to: mailto:SUNDIALS-USERS-...@LISTSERV.LLNL.GOV

[Gardner, David James]

Hi Debadutta,

 

Does “cmake --version" return 3.17.3? If so, try configuring with “cmake” rather than “ccmake”. If an older version is returned, you might need to update your PATH environment variable to include the path to where CMake 3.17.3 is installed. Updating PATH might also make a newer version of “ccmake” available (depending on how CMake 3.17.3 was built), try “ccmake --version” to see if that’s the case.

 

Hope that helps,

David

[Debadutta Prusty]

Hi David,

My "cmake--version" does return 3.17.3. I tried to configure the installation with cmake later with the options "-DENABLE_FORTRAN=ON -DENABLE_MPI=ON" since my code is in Fortran and I might need parallelization capability of the solver. But it looks like it is not taking the fortran bit. To be specific, it returns "CMake Warning: Manually-specified variables were not used by the project: ENABLE_FORTRAN" when I run the cmake command.

Another query- This version of kinsol has migrated to F2003 interface and F77 has been deprecated perhaps. Does that mean I have to change my code to Fortran 2003. I am sorry if it is silly,

Thanking you,

DP

[Gardner, David James]

Hi Debadutta,

 

To enable the F2003 interface use “-DBUILD_FORTRAN_INTERFACE=ON” rather than “-DENABLE_FORTRAN=ON”.

 

If your code is using the F77 interface to KINSOL, it’s recommended to update to the F2003 interface. This will require using the Fortran interface modules, replacing the F77 interface calls with calls to the appropriate F2003 function(s), and some minor modifications to the user-supplied function signatures e.g., the nonlinear residual function:

• F77: SUBROUTINE FKFUN (U, FVAL, IER)
• F2003: integer(c_int) function func(u, fval, user_data) result(ier) bind(C)

Hopefully, that should be most of the changes necessary but, without knowing more about the F77 code, it’s hard to say. The KINSOL F2003 examples might also be helpful, see https://github.com/LLNL/sundials/tree/main/examples/kinsol/F2003_serial

 

~David

[Gardner, David James]

My mistake, it should be BUILD_FORTRAN_MODULE_INTERFACE.

 

~David

 

From: Debadutta Prusty <debaduttap...@u.northwestern.edu>
Date: Wednesday, June 29, 2022 at 2:04 PM
To: Gardner, David James <gard...@llnl.gov>
Cc: sundials-users <sundial...@llnl.gov>
Subject: Re: [sundials-users] KINSOL latest version installation

Thank you David for the information. However, the cmake problem still remains. It still gives the warning "CMake Warning:

  Manually-specified variables were not used by the project:

    BUILD_FORTRAN_INTERFACE
"

[Debadutta Prusty]

In my F77 code, the variable types are real(dp) and integer. It's a long code, consisting of multiple files with multiple subroutines. Now, since the examples given in the F2003_serial folder use integer (c_int), real(c_double) and type(N_Vector), will I have to change only the corresponding input and output variables in the main program, leaving everything else unchanged?

[Balos, Cody Joe]

Hi Debadutta,

 

The changes are a bit more involved than just changing the types. The SUNDIALS functions to call are different as well. You should not need significant restructuring of the code though. Ill note that the Fortran 2003 interface closely follows the C interface. I recommend reviewing the Fortran 2003 examples in the SUNDIALS repository to understand what needs to be changed.

 

Cheers,

Cody

[Debadutta Prusty]

Thanks Cody. I am doing just that. By "leaving everything else unchanged", I meant outside the subroutines associated with sundials, things wouldn't have to be changed except the ones entering and exiting these subroutines.

[Debadutta Prusty]

Is it the case that all variables inside sundials functions, such as func, jactimes, etc., have to be in c variable types? The reason I ask this is because in my original code, in the fkfun subroutine, I had made several calls to subroutines from different modules, which used fortran variable types such as real(dp), integer, etc.. If all the variables inside func have to be in c types, I guess a major modification of the code is due since corresponding changes must be made in the subroutines that are being called from func.

Thanks,

Debadutta Prusty  

[Debadutta Prusty]

Also are constraints not required anymore in the program? I did not see any mention of "KINSetConstraints" in the example folder programs.

[Balos, Cody Joe]

Hi Debadutta,

The underlying types that SUNDIALS provides to the callback functions functions are the C types from the ISO_C_BINDING module. If the types are compatible (in a loose sense, i.e. not necessarily strictly adhering to what the standard guarantees) with the types you use internally, e.g. real(KIND=8) and real(c_double), then you do not need to update those internal subroutines.

KINSetConstraints still exists, although it has never been a required function, just optional. See https://sundials.readthedocs.io/en/latest/kinsol/Usage/index.html?highlight=KINSetConstraints#c.KINSetConstraints. If you read https://sundials.readthedocs.io/en/latest/sundials/Fortran_link.html, you'll notice that this function will be named FKINsetConstraints in Fortran.

Regards,

Cody

---

From: sundials-users <sundial...@llnl.gov> on behalf of Debadutta Prusty <debaduttap...@U.NORTHWESTERN.EDU>

Sent: Thursday, June 30, 2022 8:39 PM
To: sundials-users <sundial...@llnl.gov>

[Debadutta Prusty]

Thanks a lot Cody.

Unfortunately, I have another question. According to one of your replies in another post,  the nonlinear system function provided to KINInit (or FKINInit for Fortran) is the nonlinear residual function F(u). Does that mean the return value of this function should be F(u)? In the example code, the return value is an integer named ierr though F(u) is being evaluated inside it. Secondly, since the method in question is Picard, is the Jacobian in the examples evaluating the product Lv? And also is v here the iterate, the array of variables we are solving for? It is denoted by "u" in the documentation, hence the question.

Thanks,

Debadutta Prusty

[Balos, Cody Joe]

The nonlinear system function F(u) should return an integer value (0 implies success) but evaluate F(u) and store it in "fval". See https://sundials.readthedocs.io/en/latest/kinsol/Usage/index.html#c.KINSysFn for more info and other possible integer return values and what they mean.  If you are using Picard iteration, then you can provide a routine to evaluate L if you are using a direct linear solver, or you can provide routine that evaluates the matrix-vector product Lu if you are using a matrix-free iterative linear solver. An example of the latter is https://github.com/LLNL/sundials/blob/main/examples/kinsol/F2003_serial/kinLaplace_picard_kry_f2003.f90#L118.   An example of the former (in C) is https://github.com/LLNL/sundials/blob/main/examples/kinsol/serial/kinLaplace_picard_bnd.c#L286. In those examples, the routines are indeed referred to as "the Jacobian" and  "Jacobian-vector product". 

See https://sundials.readthedocs.io/en/latest/kinsol/Usage/index.html#c.KINLsJacTimesVecFn and https://sundials.readthedocs.io/en/latest/kinsol/Usage/index.html#jacobian-construction-matrix-based-linear-solvers. 

There are also options to allow KINSOL to use difference quotients to evaluate L or Lu. Some information about that is here: https://sundials.readthedocs.io/en/latest/kinsol/Usage/index.html#linear-solver-interface-optional-input-functions. 

Cody

---

From: sundials-users <sundial...@llnl.gov> on behalf of Debadutta Prusty <debaduttap...@U.NORTHWESTERN.EDU>

Sent: Friday, July 1, 2022 10:29 AM

[Debadutta Prusty]

Thanks Cody. Let's see how the whole thing goes.

[Debadutta Prusty]

How does one obtain the compiler flags for a f77 code that uses 2003 calls? It shouldn't be any different from just getting the flags by running the Makefile in the F2003_serial directory, right? I did just that. I ran the Makefile, copied the portion of the output to the left of -O3, "-I/home/debadutta/Downloads/KINSOL-INSTALL-NEW/INSTDIR/fortran -L/home/debadutta/Downloads/KINSOL-INSTALL-NEW/INSTDIR/lib -lsundials_fkinsol_mod -lsundials_kinsol -lm -Wl,-rpath,/home/debadutta/Downloads/KINSOL-INSTALL-NEW/INSTDIR/lib", and pasted that into my Makefile's LDFLAG entry. It had worked earlier for the earlier version of kinsol. But now it doesn't seem to be able to capture the flag. This shows in the compilation output in the terminal
"gfortran          -cpp -DVERSION=\"97fd0d-dirty\"  -fcheck=all  -O3    MISSING FLAGS -c precision.f90 mathconst.f90 physconst.f90 globals.f90 myutils.f90 molecule.f90 L2norm.f90 chains.f90 volume.f90 loop.f90 parameter.f90 field.f90 init.f90 chaingenerator.f90 bulk-pot.f90 integration.f90 myio.f90    ref-den-profile.f90  fcn-new.f90    kinsolsolver.f90 solver.f90  brush.weak.geo_fp.f90 "

[Debadutta Prusty]

The code compiles fine now. There were a few mistakes in the Makefile that I failed to notice. However, this new version is not able to make my problem converge while the older version did (Well it did not do that for all the cases I am interested in, otherwise I would not be turning to the newer version, but here I am talking about only the parameters that produced convergence with my previous version). It fails within 5 iterations. I tried both PICARD and linesearch.

On Sat, Jul 2, 2022 at 11:23 PM Debadutta Prusty <debaduttap...@u.northwestern.edu> wrote:

Correction- I copied the portion of the output to the right of -O3. And also I realized that the flags not showing up in the initial compilation command is not an error. It's just the way it is done in normal processes. However, my code doesn't compile due to a few intrinsic subroutines not being recognized. I am attaching the error message and the relevant portion of my Makefile below.

# put the name of the target program here
TARGET = brush.weak.geo # the list of source files
SRC =   precision.f90 mathconst.f90 physconst.f90 globals.f90 myutils.f90 molecule.f90 L2norm.f90 chains.f90 volume.f90 loop.f90 parameter.f90 field.f90 init.f90 chaingenerator.f90 bulk-pot.f90 integration.f90 myio.f90    ref-den-profile.f90  fcn-new.f90    kinsolsolver.f90 solver.f90  brush.weak.geo_fp.f90 

# some definitions
SHELL = /bin/bash

# get git version
GIT_VERSION := $(shell git describe --abbrev=6 --dirty --always --tags)

FFLAGS=-cpp -DVERSION=\"$(GIT_VERSION)\"  -fcheck=all  -O3                    

LDFLAGS= -I/home/debadutta/Downloads/KINSOL-INSTALL-NEW/INSTDIR/fortran -L/home/debadutta/Downloads/KINSOL-INSTALL-NEW/INSTDIR/lib -lsundials_fkinsol_mod -lsundials_kinsol -lm -Wl,-rpath,/home/debadutta/Downloads/KINSOL-INSTALL-NEW/INSTDIR/lib


# -lm /usr/lib/x86_64-linux-gnu/librt.so -L/home/debadutta/sundials/instdir/lib -lsundials_fkinsol -lsundials_kinsol -lsundials_fnvecserial -lsundials_nvecserial  /usr/lib/liblapack.so /usr/lib/libblas.so   -Wl,-rpath,/home/debadutta/sundials/instdir/lib

#-I/home/debadutta/Downloads/KINSOL-INSTALL-NEW/INSTDIR/fortran -L/home/debadutta/Downloads/KINSOL-INSTALL-NEW/INSTDIR/lib -lsundials_fkinsol_mod -lsundials_kinsol -lm -Wl,-rpath,/home/debadutta/Downloads/KINSOL-INSTALL-NEW/INSTDIR/lib

LFFLAGS=$(LDFLAGS)

FF=  /usr/bin/mpif90


all:    $(TARGET)

$(TARGET): $(SRC:.f90=.o)
    $(FF) -o $(TARGET) $(SRC:.f90=.o)  $(LDFLAGS) $(LFLAGS)

#$(SRC:.f90=.o):    
#    ${FF} -c ${FFLAGS}  $(SRC)

%.o: %.f90
#.f90.o :
    ${FF} ${FFLAGS} -c $(SRC)

install: all
    cp $(TARGET) ~/bin


clean:   
    @rm -f $(SRC:.f90=.o) $(SRC:.f90=.d) $(TARGET) *~ *.mod

realclean: clean
    @rm -f .depend

depend dep:
    @$(FF)  $(CFLAGS) -MM $(SRC) > .depend

ifeq (.depend, $(wildcard .depend))
include .depend
endif

So what I did is copied the portion of the output message of the example programs to the left of -O3 and pasted it in the entry for LDFLAGS, which is highlighted in red above. The errors generated are given below.

fcn-new.f90:26:8:

     use fsundials_nvector_mod
        1
Fatal Error: Can't open module file ‘fsundials_nvector_mod.mod’ for reading at (1): No such file or directory
compilation terminated.

Since the error is with this newly introduced subroutine in the code, I believe the flags I am getting are wrong, probably due to my faulty understanding of extracting linker flags.

[Debadutta Prusty]

My L matrix is an identity matrix.

[Debadutta Prusty]

[Debadutta Prusty]

An update- Making the L matrix I*x, where x is greater than 10 made the code converge in one case. However, for the next parameter in the sweep process (I am looping over different parameters, using the solution of one as the initial guess for the next), the code blew up.  So, I believe the success with Picard iteration hinges on how judiciously L is set. Easier said than done. In my case, the equations are integral equations, which makes the computation of Jacobian an absolute nightmare. So, the whole game is basically reduced to having shots at different values of L through adjustments in x blindly.  Any different takes on this?