Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linking against metis and gklib #9

Open
fabiodelogu opened this issue Apr 21, 2023 · 3 comments
Open

Linking against metis and gklib #9

fabiodelogu opened this issue Apr 21, 2023 · 3 comments

Comments

@fabiodelogu
Copy link

fabiodelogu commented Apr 21, 2023

Hi @ivan-pi,

I am currently working on metis and mpi libraries to optimize our hydrological system modelling; all the codes. tools and modules are freely available on github at https://github.com/c-hydro.

(1)
To compile your fmetis libraries i had to add the gklib to the linking process;
cmake .. -DCMAKE_Fortran_COMPILER=gfortran -DMETIS_LIB="$HOME/metis_workspace/lib/libmetis.a" -DGK_LIB="$HOME/metis_workspace/lib/libGKlib.a" -DCMAKE_INSTALL_PREFIX="$HOME/metis_interface/"

(2)
and I added the GK_LIB in the CMAKE file too (ll 74-75):

add_library(fmetis src/lib/metis_interface.f90 src/lib/metis_oo_interface.f90)
target_link_libraries(fmetis ${METIS_LIB} ${GK_LIB})

Some tests failed, but I am using the libraries to interface my simple metis fortran program to the metis library.

This probably is due to the the new (?) approach to compile metis that, if I correctly understood, it is divided in two parts:

(1) gklib
...
make config cc=gcc prefix="$HOME/metis_workspace" openmp=set
make install
(2) metis
...
make config r64=1 i64=1 cc=gcc gdb=1 gklib_path=$HOME/metis_workspace/ prefix=$HOME/metis_workspace/
make install

Is it correctly or I missed some remarks or suggestions?
I hope I am not wasting your time with unuseful comments or questions

All the best
Fabio

@ivan-pi
Copy link
Owner

ivan-pi commented Apr 21, 2023

Hi Fabio,

it's been a few years since I wrote these modules. I was still learning CMake at the time and wasn't really aware of all the best practices. I can't recall if I was installing METIS from source or via the Aptitude package manager myself.

If I redid this today, I would probably try to make the CMake file compatible with the METIS version packaged for CMake here: https://github.com/scivision/METIS

In principle you could just drop the file metis_interface.f90 into your existing source tree, and not rely on this CMake file at all.

The other useful part of this project are the tests (or examples) provided here: https://github.com/ivan-pi/fmetis/tree/master/src/tests

I'd be curious to learn why the tests failed. The possible explanations off the top of my head are: 1) the integer/real size doesn't match the METIS library, 2) there is an indexing error due to the 0- vs 1-based indexing, 3) some example graph file is missing.

If you have any other suggestions for improvements, please let me know.

Ciao,

Ivan

@ivan-pi
Copy link
Owner

ivan-pi commented Apr 21, 2023

You are absolutely correct about the two-step installation process, it would be worth updating the README here to points towards the KarypisLab GitHub repositories:

Also the CMakeList needs to be corrected to account for the GKlib path.

@fabiodelogu
Copy link
Author

fabiodelogu commented Jun 9, 2023

Hi @ivan-pi,
I have another couple of questions related to how to set the fortran indexing format for the results;
at the moment I was running this code:
....
# dataset:
metis_data_eptr = 0 4 8 12 16 20 24
metis_data_eind = 0 1 5 4 1 2 6 5 2 3 7 6 4 5 9 8 5 6 10 9 6 7 11 10

! Variable(s) metis
metis_ios = METIS_SetDefaultOptions(metis_opts)
if (metis_ios /= METIS_OK) then
    write(*,*) "METIS_SetDefaultOptions failed with error: ", metis_ios
    error stop 1
end if
!metis_opts(17) = 1
metis_opts(METIS_OPTION_NUMBERING) = 1              ! Fortran-style numbering
metis_opts(METIS_OPTION_CONTIG) = 1                     ! Force contiguous partitions
metis_opts(METIS_OPTION_DBGLVL) = METIS_DBG_INFO    ! Show various diagnostic messages

metis_ios = METIS_PartMeshNodal(metis_elements, metis_vertex, &
                          metis_data_eptr, metis_data_eind, &
                          nparts=metis_parts, options=metis_opts, &
                          objval=metis_cuts, epart=metis_epart, npart=metis_npart)

...
and the result that I obtained are:
metis_data_eptr = 0 4 8 12 16 20 24
metis_data_eind = 0 1 5 4 1 2 6 5 2 3 7 6 4 5 9 8 5 6 10 9 6 7 11 10
metis_unique eind = 0 1 5 4 2 6 3 7 9 8 10 11
metis_cuts = 17
metis_epart = 1 1 3 0 1 2
metis_npart = 1 1 3 3 0 1 3 2 0 0 2 2

In my idea, I expected the "metis_epart" and "metis_npart" have to start from 1 until the number of cores that I want to use. I had the same behaviour with other tests:
metis_data_eptr = [1,5,9,13,17]
metis_data_eind = [1,2,5,4, 2,3,6,5, 4,5,8,7, 5,6,9,8] or metis_data_eind = [1,2,3,4, 2,5,6,3, 3,6,7,8, 4,3,8,9].

It seems that the condition is not correctly passed to the c routine; but, for example, the option for the debug get activated or not according to the fortran program settings.
Do you have any advice or idea to solve the problem or change the behaviour of the fortran interface?

The second is related to the "metis_npart" array because I am not sure how the results are stored:
(1) according with the incremental index of the vertexes
or
(2) according with the "metis_unique_eind" array

Do you remember something about this point?

Again thank you for your time; and if you don't have the time to answer really don't worry. If you need the complete code of my tests, you feel free to ask me it.

Ciao
Fabio

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants