ScalES-PPM: Issueshttps://swprojects.dkrz.de/redmine/https://swprojects.dkrz.de/redmine/redmine/favicon.ico?17095821032020-08-13T18:32:36ZDKRZ projects
Redmine Bug #350 (Resolved): pkg-config file libraries results in overlinkinghttps://swprojects.dkrz.de/redmine/issues/3502020-08-13T18:32:36ZMatthew Krupcale
<p>The <code>scales-ppm{,-core}.pc.in</code> pkg-config files specifies several libraries in the <code>Libs:</code> portion which are actually internal, private library dependencies of scales-ppm. That is, they are not part of the public interface/API and are just implementation details. These should be specified instead in <code>Libs.private:</code> so that they are only added to the link when creating a static library.</p>
<p>Similarly, the MPI includes are part of the public scales-ppm-core API, so we need to include those, but we don't need parmetis or metis includes here (in any case, they should have been in <code>scales-ppm.pc.in</code>, not <code>scales-ppm-core.pc.in</code>, but they're not needed there either since they're again not part of the public API).</p>
<p>See attached patch and [1-2] for how libraries should be specified for linking.</p>
<p>[1] <a class="external" href="https://people.freedesktop.org/~dbn/pkg-config-guide.html">https://people.freedesktop.org/~dbn/pkg-config-guide.html</a><br />[2] <a class="external" href="https://cmake.org/pipermail/cmake/2016-May/063400.html">https://cmake.org/pipermail/cmake/2016-May/063400.html</a></p> Bug #349 (Resolved): Missing MPI include file for non-MPI buildshttps://swprojects.dkrz.de/redmine/issues/3492020-08-13T16:37:05ZMatthew Krupcale
<p>The include file <code>mpi_fc_conf.inc</code> is generated only for MPI builds. This causes a problem when configuring with <code>--disable-MPI</code> and attempting to build the doxygen documentation: processing <code>src/core/ppm_std_type_kinds_mp.f90</code> causes a fatal error due to the missing include file.</p>
<p>The attached patch fixes this by only including <code>mpi_fc_conf.inc</code> when <code>USE_MPI</code> is defined.</p> Bug #346 (Feedback): Failure to apply doxygen CSS patch when building HTML documentationhttps://swprojects.dkrz.de/redmine/issues/3462017-09-25T17:53:54ZMatthew Krupcale
<p>After applying the patches in <a class="issue tracker-1 status-3 priority-4 priority-default" title="Bug: autoreconf fails due to missing file m4/ac_fc_module_output_flag.m4 (Resolved)" href="https://swprojects.dkrz.de/redmine/issues/342">#342</a> and <a class="issue tracker-1 status-3 priority-4 priority-default" title="Bug: No rule to make target 'dist_array.f90' when building HTML documentation (Resolved)" href="https://swprojects.dkrz.de/redmine/issues/345">#345</a>, running <code>autoreconf -vif</code> to rebuild the <code>configure</code> and <code>Makefiles</code>, configuring the project and running</p>
<p><code>make -C doc/unitdoc html-local</code>,</p>
<p>from the top build directory to build the HTML documentation, <code>make</code> fails when building the target <code>html-local</code> when applying the final patch to the CSS:</p>
<pre>
patch -p1 <../../../doc/unitdoc/doxygen.css.patch
patching file html/doxygen.css
Hunk #1 FAILED at 944.
1 out of 1 hunk FAILED -- saving rejects to file html/doxygen.css.rej
</pre>
<p>This might be due to a different version of <code>doxygen</code> being used and producing different CSS, but I have fixed this issue by creating a new <code>doc/unitdoc/doxygen.css.patch</code> file. The attached patch fixes this patch file at least when using <code>doxygen</code> version <code>1.8.13</code>.</p> Bug #345 (Resolved): No rule to make target 'dist_array.f90' when building HTML documentationhttps://swprojects.dkrz.de/redmine/issues/3452017-09-25T17:41:08ZMatthew Krupcale
<p>After configuring the project and running</p>
<p><code>make -C doc/unitdoc html-local</code></p>
<p>from the top build directory to build the HTML documentation, <code>make</code> fails with the following error:</p>
<p><code>make[1]: *** No rule to make target 'dist_array.f90'. Stop.</code></p>
<p>This appears to be due to <code>doc/unitdoc/Makefile.am</code> attempting to build <code>src/ppm/dist_array.f90</code> using the wrong target: from <code>src</code>, it attempts to build the target <code>dist_array.f90</code>, but it should be <code>ppm/dist_array.f90</code> as defined in <code>src/Makefile.am</code>.</p>
<p>The attached patch fixes this issue.</p> Bug #342 (Resolved): autoreconf fails due to missing file m4/ac_fc_module_output_flag.m4https://swprojects.dkrz.de/redmine/issues/3422017-09-25T16:17:00ZMatthew Krupcale
<p>When attempting to run <code>autoreconf</code> on <code>ppm-1.0.4</code>, <code>aclocal</code> fails with error:</p>
<p><code>aclocal: error: acinclude.m4:52: file 'm4/ac_fc_module_output_flag.m4' does not exist</code></p>
<p>Indeed, the file does not appear to be in the <code>m4</code> directory shipped with ScalES-PPM v1.0.4.</p>
<p>Furthermore, <code>acinclude.m4</code> attempts to include this file only if the <code>autoconf</code> version is less than <code>2.70</code> (which does not yet exist), but <code>AC_FC_MODULE_OUTPUT_FLAG</code> was introduced in version <code>2.69</code> (specifically commit <code>ac427166c5945445e307c82d44301da9480f017a</code>).</p>
<p>The attached patch fixes these two issues.</p> Bug #297 (Assigned): Fix i4 assumptions in multiple routineshttps://swprojects.dkrz.de/redmine/issues/2972012-01-02T16:02:29ZThomas Jahnsjahns@dkrz.de
<p>In the Fortran 90 part of the library, to always suit default kind INTEGER arguments, many generics only have specific implementations with default INTEGER arguments, because an i8 implementation wasn't needed so far. Unfortunately for bridging the gap to C several of these routines also assume default kind equals i4. Thus it would be preferable to have implementations for both i4 and i8 resulting in generics which work on any setting of default integer kind.</p> Bug #286 (New): Fix test for FPU precision correction codehttps://swprojects.dkrz.de/redmine/issues/2862011-09-19T15:48:49ZThomas Jahnsjahns@dkrz.de
<p>Currently the test wether FPU precision correction is always invoked even if, because of SSE or otherwise correct handling of 32/64bit quantities in the FPU, no correction is necessary.</p>
<p>configure.ac should be improved with a test for wether correction is necessary.</p>