search

giacrossi / WenOOF

WENO interpolation Object Oriented Fortran library
3 stars 0 forks source link

Problem with associate #10

Closed giacrossi closed 7 years ago

giacrossi commented 7 years ago

Maybe is necessary an associate construct for IS_type in https://github.com/giacombum/WenOOF/blob/master/src/lib/type_weno_interpolator_js.f90#L146? The pointer seems not associate, maybe the problem is that the call at https://github.com/giacombum/WenOOF/blob/master/src/lib/type_weno_interpolator_js.f90#L146 doesn't pass the right argument?

szaghi commented 7 years ago

@giacombum

In general, you should show the whole error, your description is not clear and your conclusion could be wrong. When you ask for help simply show the error.

In this case your probably right, the multi-reference trough multiple % is not supported, wrap all into an associate block.

giacrossi commented 7 years ago

@szaghi

Youu're right, I've been too much rushed. When I try to execute the simple sin reconstruction test, with ifort 16.0.3 I receive this error: /tests/sin_reconstruction forrtl: severe (408): fort: (7): Attempt to use pointer IS when it is not associated with a target Image PC Routine Line Source sin_reconstructio 00000000008D1F66 Unknown Unknown Unknown sin_reconstructio 00000000008952E9 type_weno_interpo 147 type_weno_interpolator_js.f90 sin_reconstructio 00000000008AC222 wenoof_mp_create_ 99 wenoof.f90 sin_reconstructio 00000000008C86A1 MAIN__ 43 sin_reconstruction.f90 sin_reconstructio 00000000004026EE Unknown Unknown Unknown libc.so.6 00007F5541F72291 Unknown Unknown Unknown sin_reconstructio 00000000004025EA Unknown Unknown Unknown

I don't know if the multi-reference trough multiple % problem is in the input of the subroutine create at https://github.com/giacombum/WenOOF/blob/master/src/lib/wenoof.f90#L96 or in the function associate at https://github.com/giacombum/WenOOF/blob/master/src/lib/type_weno_interpolator_js.f90#L146.

What do you think?

The associate block must be inserted in the wenoof.f90 procedure before the call or in the type_weno_interpolator_js.f90 procedure?

giacrossi commented 7 years ago

Stranger behaviour: I'm trying to investigate the problem with debugger: I'm at this position: `(gdb) where

0 wenoof::create (constructor=..., is_type=..., alpha_type=..., alpha_base_type=...,

weights_opt_type=..., polynomial_type=..., interpolator=0xc75080, .tmp.IS_TYPE.len_V$a0d=2, 
.tmp.ALPHA_TYPE.len_V$a10=2, .tmp.ALPHA_BASE_TYPE.len_V$a13=0, .tmp.WEIGHTS_OPT_TYPE.len_V$a16=2, 
.tmp.POLYNOMIAL_TYPE.len_V$a19=2) at src/lib/wenoof.f90:95

1 0x000000000091c7e8 in sin_reconstruction () at src/tests/sin_reconstruction.f90:43

2 0x0000000000402aae in main ()

3 0x00007ffff7330b45 in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6

4 0x00000000004029a9 in _start ()`

where I have already allocated all the components of the interpolator. If I ask to the debugger for what type the components are, I obtain this strange reply: (gdb) whatis interpolator type = PTR TO -> ( weno_interpolator ) (gdb) whatis interpolator%IS Location address is not set. (gdb) whatis interpolator%alpha type = PTR TO -> ( weno_alpha_coefficient ) (gdb) whatis interpolator%weights Location address is not set. (gdb) whatis interpolator%polynom Location address is not set.

So the unique succesful allocate operations seem that for the interpolator itself and the alpha coefficients.

szaghi commented 7 years ago

@giacombum

PENF issue

You have correctly set the .gitmodules config file to point to the master branch, but... after that you have to sync your WenOOF fork with that branch by means of a commit against a fresh pull of PENF master branch... that is

cd /path/to/your/WenOOF/
git status
git commit -a -m "safety snapshot"
git submodule update --init --recursive
cd src/third_party/PENF
git checkout master
git pull
cd -
git add src/third_party/PENF
git commit -m "update PENF to current master"

Git submodules are cumbersome...

giacrossi commented 7 years ago

@szaghi Thank you for solving my issue with submodules!

szaghi commented 7 years ago

@giacombum

The current version of your fork has many (too much) issues... before debug it, I need a more clean source. They are easy to fix, but require time that I have not. The following is an incomplete list of such issues:

→ FoBiS.py build -mode tests-intel-debug
...

This generates, among other things, the following warnings

src/lib/type_weno_alpha_coefficient_js.f90(38): warning #5268: Extension to standard: The text exceeds right hand column allowed on the line.
!< Check the type of the alpha coefficient passed as input and return a Jiang-Shu alpha coefficient associated to the alpha coefficient.

src/lib/type_weno_alpha_coefficient_js.f90(76): remark #7712: This variable has not been used.   [IS]
  pure function compute(self, S, weight_opt, IS, IS_i, eps) result(alpha)
---------------------------------------------^

src/lib/type_weno_alpha_coefficient_js.f90(76): remark #7712: This variable has not been used.   [SELF]
  pure function compute(self, S, weight_opt, IS, IS_i, eps) result(alpha)
------------------------^

src/lib/type_weno_alpha_coefficient_z.f90(45): warning #5268: Extension to standard: The text exceeds right hand column allowed on the line.
!< Check the type of the alpha coefficient passed as input and return a WENO Z alpha coefficient associated to the alpha coefficient.
------------------------------------------------------------------------------------------------------------------------------------^
src/lib/type_weno_alpha_coefficient_z.f90(85): remark #7712: This variable has not been used.   [SELF]
  pure function compute(self, S, weight_opt, IS, IS_i, eps) result(alpha)
------------------------^
src/lib/type_weno_alpha_coefficient_z.f90(59): remark #7712: This variable has not been used.   [SELF]
  pure subroutine description(self, string)
------------------------------^

src/lib/type_weno_alpha_coefficient_m.f90(44): warning #5268: Extension to standard: The text exceeds right hand column allowed on the line.
!< Check the type of the alpha coefficient passed as input and return a WENO M alpha coefficient associated to the alpha coefficient.
------------------------------------------------------------------------------------------------------------------------------------^
src/lib/type_weno_alpha_coefficient_m.f90(58): remark #7712: This variable has not been used.   [SELF]
  pure subroutine description(self, string)
------------------------------^

src/lib/type_weno_optimal_weights_js.f90(201): remark #7712: This variable has not been used.   [SELF]
  pure subroutine description(self, string)
------------------------------^

src/lib/type_weno_smoothness_indicators_js.f90(43): warning #5268: Extension to standard: The text exceeds right hand column allowed on the line.
!< Check the type of the smoothness indicator passed as input and return a Jiang-Shu smoothness indicator associated to the smoothness indicator.
------------------------------------------------------------------------------------------------------------------------------------^
src/lib/type_weno_smoothness_indicators_js.f90(2347): remark #7712: This variable has not been used.   [SELF]
  pure function compute(self, smooth_coef, v1, v2) result(IS)
------------------------^
src/lib/type_weno_smoothness_indicators_js.f90(2325): remark #7712: This variable has not been used.   [SELF]
  pure subroutine description(self, string)
------------------------------^

src/lib/type_weno_polynomials_js.f90(173): warning #5268: Extension to standard: The text exceeds right hand column allowed on the line.
        c(1,0,0)=    1._R_P/7._R_P  ; c(1,1,0)=  223._R_P/140._R_P; c(1,2,0)= -197._R_P/140._R_P; c(1,3,0)=  153._R_P/140._R_P  ! stencil 0
------------------------------------------------------------------------------------------------------------------------------------^
src/lib/type_weno_polynomials_js.f90(190): warning #5268: Extension to standard: The text exceeds right hand column allowed on the line.
        c(1,0,0)=  363._R_P/140._R_P; c(1,1,0)= -617._R_P/140._R_P; c(1,2,0)=  853._R_P/140._R_P; c(1,3,0)=-2341._R_P/420._R_P  ! stencil 0
------------------------------------------------------------------------------------------------------------------------------------^
...

Fix all the unused variable: if self is not used, the TBP should have a nopass attribute. Extensions to the standard could (probably not) related to your segfalt. Before any further debugging activities, such a minor issues should be fixed: debugging for a new bug a known-bugged code (the compiler has found a lot of warnings) is meaningless if those known-bugs are not already fixed.

giacrossi commented 7 years ago

Some of the warning you rightly noticed have been fixed in d627d261e509468acef4478fe52f0df5d21d94db.

Some problems of unused variables (self and IS of course) haven't been solved because of the design of the alpha coefficients API.

At the moment I haven't any idea of how I can improve the API to avoid the use of optional arguments and pass attribute where I don't need it: feel free (and very welcome!) if you have some ideas for this topic.

The problem with associate is anyway still here.

giacrossi commented 7 years ago

@szaghi See here 0063bb1beb7e69e6120faf644f9094c4427d0ccf: a new API to rule them all!!!! What do you think about it? Now I've to resolve the other issue (the extension to standard for line width).

giacrossi commented 7 years ago

With commit 75c3d61a1c12a1ef05b59032b410425093cd4e1d also the line width are fixed.

giacrossi commented 7 years ago

@szaghi The problem is still here. When I try to test the module_imports program on the develop branch after the commit 9fb38db4ff183fc009cb9d269c1e8a1127b5c56e, I obtain the following error

./tests/modules_imports forrtl: severe (408): fort: (7): Attempt to use pointer IS when it is not associated with a target Image PC Routine Line Source modules_imports 00000000009139F6 Unknown Unknown Unknown modules_imports 00000000008FA011 type_weno_interpo 150 type_weno_interpolator_js.f90 modules_imports 000000000090D4F0 wenoof_mp_create_ 93 wenoof.f90 modules_imports 000000000090DA2B MAIN__ 19 modules_imports.f90 modules_imports 0000000000402AAE Unknown Unknown Unknown libc-2.19.so 00007FBED4CB0B45 __libc_start_main Unknown Unknown modules_imports 00000000004029A9 Unknown Unknown Unknown

and if I try to investigate with the debugger, when I'm here, the only one pointer that is associated is the interpolator one, while all the others (interpolator%alpha, interpolator%IS, ecc...) aren't. Do you have any ideas about it?

szaghi commented 7 years ago

There are some issues with the master branch (arguing it is aligned with the develop one)

Compiling GNU gfortran (6.2.1) in debug mode

stefano@zaghi(02:13 PM Thu Nov 24) on master
~/downloads/WenOOF 7 files, 84Kb
→ FoBiS.py build -mode tests-gnu-debug
...

Running the sin reconstruction test

stefano@zaghi(02:13 PM Thu Nov 24) on master
~/downloads/WenOOF 8 files, 88Kb
→ ./tests/sin_reconstruction
At line 80 of file src/lib/type_weno_smoothness_indicators_js.f90
Fortran runtime error: Attempting to allocate already allocated variable 'self'

Error termination. Backtrace:
#0  0x42599b in __type_weno_smoothness_indicators_js_MOD_create
        at src/lib/type_weno_smoothness_indicators_js.f90:80
#1  0x4ef139 in __type_weno_interpolator_js_MOD_create
        at src/lib/type_weno_interpolator_js.f90:146
#2  0x4fb492 in __wenoof_MOD_create
        at src/lib/wenoof.f90:94
#3  0x4fbacd in sin_reconstruction
        at src/tests/sin_reconstruction.f90:44
#4  0x4fc419 in main
        at src/tests/sin_reconstruction.f90:8

Looking at the code I find

This is the reason why Intel compiler complains.... When a Compiler does not provide a clear error message try another compiler...

giacrossi commented 7 years ago

Thanks for the help, I've fixed the error you've pointed to me in the commit 071875e4065cc8d2e54666d2446bc5a513e15bf7. But the problem with the pointers is still here, and now I think that ifort and gfortran point to the same error...

After compiling with GNU gfortran (6.2.1) in debug mode, running the module imports test

eugenio@SAI-Linux:~/Giacomo/fortran/WenOOF$ ./tests/modules_imports 
*** Error in `./tests/modules_imports': free(): invalid pointer: 0x00007f4619f48678 ***

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x7f4619bd80df in ???
#1  0x7f4619bd8067 in ???
#2  0x7f4619bd9447 in ???
#3  0x7f4619c161b3 in ???
#4  0x7f4619c1b98d in ???
#5  0x7f4619c1c695 in ???
#6  0x4bc5f8 in __type_weno_smoothness_indicators_js_MOD_destroy
        at src/lib/type_weno_smoothness_indicators_js.f90:66
#7  0x42570e in __type_weno_smoothness_indicators_js_MOD_create
        at src/lib/type_weno_smoothness_indicators_js.f90:80
#8  0x4ef027 in __type_weno_interpolator_js_MOD_create
        at src/lib/type_weno_interpolator_js.f90:146
#9  0x4f0071 in __wenoof_MOD_create
        at src/lib/wenoof.f90:94
#10  0x4f01bb in module_imports
        at src/tests/modules_imports.f90:20
#11  0x4f02c6 in main
        at src/tests/modules_imports.f90:7

And after compiling with ifort 17.0.0 in debug mode, running the module imports test

eugenio@SAI-Linux:~/Giacomo/fortran/WenOOF$ ./tests/modules_imports                                                                                                                                              
forrtl: severe (408): fort: (7): Attempt to use pointer IS when it is not associated with a target

Image              PC                Routine            Line        Source             
modules_imports    0000000000913C66  Unknown               Unknown  Unknown
modules_imports    00000000008FA27D  type_weno_interpo         146  type_weno_interpolator_js.f90
modules_imports    000000000090D75C  wenoof_mp_create_          93  wenoof.f90
modules_imports    000000000090DC97  MAIN__                     19  modules_imports.f90
modules_imports    0000000000402AAE  Unknown               Unknown  Unknown
libc-2.19.so       00007F20B06BAB45  __libc_start_main     Unknown  Unknown
modules_imports    00000000004029A9  Unknown               Unknown  Unknown

So, ifort was only just more indulgent than gfortran...

giacrossi commented 7 years ago

solved