#146 Package iso2mesh: MATLAB/Octave-based mesh generation toolbox
Closed: Fixed 4 years ago by fangq. Opened 5 years ago by mhough.

URL: http://iso2mesh.sourceforge.net

GitHub URL: https://github.com/fangq/iso2mesh

iso2mesh is a fully octave compatible toolbox for tetrahedral mesh generation needed for finite element modeling. The toolbox is the requirement for one brain model pipeline script that is a part of another toolbox MCX (http://mcx.space/)


The details of this toolbox can be found in the following

Anh Phong Tran and Qianqian Fang, "Fast and high-quality tetrahedral
mesh generation from neuroanatomical scans," arXiv preprint arXiv:1708.08954, 2017

Qianqian Fang and David Boas, "Tetrahedral mesh generation from volumetric binary and
gray-scale images," Proceedings of IEEE International Symposium on Biomedical Imaging
(ISBI 2009), pp. 1142-1145, 2009

Following the build instructions

git clone --recurse-submodules https://github.com/fangq/iso2mesh.git
cd iso2mesh
rm -rf bin/.mex bin/*.exe
cd tools
make clean

Current CGAL-4.14 requires a change in


CGAL/AABB_intersections.h -> CGAL/intersections.h

I have asked upstream about another build problem (w/ the meshfix tool) that doesn't appear to be CGAL related:


Metadata Update from @mhough:
- Issue unmarked as depending on: #181

4 years ago

hi @mhough, I reactivated my fedora account (keep inactive for almost 10 years), and joined the neurofedora sig.

I also installed a fc30 virtual machine on my linux system, and made some progress on packaging iso2mesh. After a few minor changes and a few packages, I was able to compile/run iso2mesh on fc30 using the provided octave 4.4.1.

A screenshot of the working iso2mesh can be found at the bottom.

A few steps to make this work:

  1. needed build dependencies:
    sudo dnf install cmake CGAL-devel SuperLU SuperLU-devel blas-static tetgen
  2. I updated iso2mesh cgalmesh source code to use the new intersections.h header file
  3. I updated cork's Makefile to use gcc/g++ instead of clang; I also updated meshfix to include slu_cdefs.h with the right path, see

after that, all binaries can be compiled and generated under iso2mesh/bin. I only compile for tetgen1.5 from git, and rely on system to provide tetgen (which on fc30 is the same as tetgen1.5 - iso2mesh previously assumes tetgen is for tetgen1.4.3, but this is ok).

After that, majority of iso2mesh functions will be readily usable in octave. I tested most of demo scripts, about 70% worked, most of the failures were related to the missing of octave-image. I would prefer not to place octave-image as a dependency to iso2mesh, and only ask users to install when then need those functions.

Let me know if you are interested in giving this a try. simply

git clone --recursive https://github.com/fangq/iso2mesh.git 

should grab the latest updated files.

let me know if you have new problems.


@mhough and @ankursinha, I'd like to get some help from you guys on finishing the spec file for packaging iso2mesh

here is my current version

I got everything working (compilation) until %octave_pkg_build in the %build section, and the error was it looks for


but only


the above suffix is only generated when buildarch is set to noarch, but this is not the case in my spec file.

I tracked this down to macros.octave, and it did choose the 1st branch where buildarch is not noarch

but somehow, pkg install command still produces the any-non.tar.gz tarball.

do you spot anything in my spec file that might cause this issue?

thanks, if I get this around, should be able to finish the spec file today and submit for a new package.

just to clarify - what actually went wrong was this line in the macros.octave file

print(rpm.expand("octave -H -q --no-window-system --no-site-file --eval 'pkg build -verbose -nodeps %{_builddir}/%{buildsubdir} "..octpkg_tarfile).."'\\n")

because it did not generate the right suffix, the if/else branch got the correct suffix, but failed afterwards as the desired suffixed tarball was not generated in the above pkg build line.

Hey @fangq,

So great to have you in NeuroFedora! I am at NYC Neuromodulation right now but will look at this soon. ROAST developers are here and they are built on top of iso2mesh BTW.

@mhough and @ankursinha after several hours of reading/testing, I moved this forward a little bit

it turns out that the issue is related to this redhat bug


that the %octave_pkg_install function in macros.octave (part of octave-devel) was written in shell script but %octave_pkg_build was written in lua, and the octave_tar_suffix defined in pkg_build is not passed on to pkg_install.

from what I can see (through many tests), the current octave_pkg_install can only handle buildarch=noarch, but not mex files with buildarch!=noarch.

To get around this issue, I found a solution from this link


where I can set BuildArch to noarch, and set ExclusiveArch to desired arch to build. With this change


I was able to pass the previous error. I got a new error which is related to the .debug file generated from the compilation stage.

[Update]: it looks like octave_pkg_build did pass on the correct octave_tar_suffix to octave_pkg_install. It must be somewhere the octave pkg command failed to get the correct suffix and produced the -any-none.tar.gz tarball.

Metadata Update from @fangq:
- Issue unmarked as depending on: #176
- Issue assigned to fangq

4 years ago


new package submitted at https://bugzilla.redhat.com/show_bug.cgi?id=1758626

for some reason, I can't link this pagure url in bugzilla. added @mhough and @ankursinha to the tracker. will send a review request in the mailing list.

Metadata Update from @fangq:
- Issue tagged with: S: In testing

4 years ago

Metadata Update from @fangq:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

4 years ago

Login to comment on this ticket.

Attachments 1
Attached 4 years ago View Comment