cc_staff
1,857
edits
mNo edit summary |
mNo edit summary |
||
Line 950: | Line 950: | ||
==== Compiled UDF ==== <!--T:522--> | ==== Compiled UDF ==== <!--T:522--> | ||
To use this approach | To use this approach your UDF must be compiled on an alliance cluster at least once. Doing so will create a libudf subdirectory structure containing the required <code>libudf.so</code> shared library. The libudf directory cannot simply be copied from a remote system (such as your laptop) to the Alliance since the library dependencies of the shared library will not be satisfied resulting in fluent crashing on startup. That said once you have compiled your UDF on one Alliance cluster you can transfer the newly created libudf to any other Alliance cluster providing your account there loads the same StdEnv environment module version. Once copied, the UDF can be used by uncommenting the second (load) libudf line below in your journal file when submitting jobs to the cluster. Both (compile and load) libudf lines should not be left uncommented in your journal file when submitting jobs on the cluster otherwise your UDF will automatically (re)compiled for each and every job. Not only is this highly inefficient, but also it will lead to racetime-like build conflicts if multiple jobs are run from the same directory. Besides configuring your journal file to build your UDF, the fluent gui (run on any cluster compute node or gra-vdi) may also be used. To do this one would navigate to the Compiled UDFs Dialog Box, add the UDF source file and click Build. When using a compiled UDF with parallel jobs your source file should be parallelized as discussed in the section below. | ||
define/user-defined/compiled-functions compile libudf yes sampleudf.c "" "" | define/user-defined/compiled-functions compile libudf yes sampleudf.c "" "" |