# Package for level-set method?

22 messages
12
Open this post in threaded view
|

## Package for level-set method?

 Hi all! For my PhD, I'm working on shape optimisation with the level-set method.  The basic idea here is to describe geometries / domains via a level-set function phi, such that the domain is given as the open set   { x | phi(x) < 0 }. By calculating the viscosity solutions of the level-set equation   phi_t(x, t) + F(x) | gradient phi(x, t) | = 0, one can perform "changes" of the geometry('s level-set function) that correspond to movement of the boundary in normal direction according to the given speed-field F. Using a proper discretisation scheme, this equation can be propagated in time.  However, it is also possible to find the resulting geometries by solving the stationary Eikonal equation   F(x) | gradient d(x) | = 0 first, whose solution d can be used to find the evolved geometries at arbitrary times t >= 0.  d can be calculated numerically using the Fast Marching method, as described, for instance, by Sethian.  I'm working on a theoretical paper about this at the moment, but also have working implementations already. I would be interested to polish my code and release it as free software to Octave Forge if there is interest.  (Will have to ask my employer (University of Graz) first for permission, but I think that should be ok.) What I have and could release: * Implementation of the Fast Marching method to solve the equation for d given arbitrary F (need not be strictly positive or something like this).  It works on structured (rectangular) grids of any dimension and with the possibility to exclude certain grid points from the possible domain. * Calculation of the level-set function for evolved domains based on this.  I'm currently using this on a structured grid in two dimensions, but I think the code should handle arbitrary dimensions just fine.  (Or I can extend it to do so.) * Determining geometrical properties from the level-set function, including a polygonal approximation of the boundary and calculation of a triangle mesh for the described domain.  This works in 2D and my mesh structure is currently a bit different from the one used in the msh and fem-fenics packages, but it shouldn't be hard to rewrite the code to generate meshes fitting to msh / fem-fenics. In the future, I may also work on allowing more general meshes (for instance, finer where the boundary movements must be resolved, but coarser in the interior for more efficient PDE solving), and can maintain the package accordingly. Would you be interested in this package to be relased on Octave Forge, or do you think it is not of general interest? Yours, Daniel -- http://www.domob.eu/OpenPGP: 901C 5216 0537 1D2A F071  5A0E 4D94 6EED 04F7 CF52 Namecoin: id/domob -> https://nameid.org/?name=domob-- Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz To go: Mon-Pri smime.p7s (5K) Download Attachment
Open this post in threaded view
|

## Re: Package for level-set method?

 On Wed, Mar 12, 2014 at 1:28 PM, Daniel Kraft <[hidden email]> wrote: > Hi all! > > For my PhD, I'm working on shape optimisation with the level-set method. >  The basic idea here is to describe geometries / domains via a level-set > function phi, such that the domain is given as the open set > >   { x | phi(x) < 0 }. > > By calculating the viscosity solutions of the level-set equation > >   phi_t(x, t) + F(x) | gradient phi(x, t) | = 0, > > one can perform "changes" of the geometry('s level-set function) that > correspond to movement of the boundary in normal direction according to > the given speed-field F. > > Using a proper discretisation scheme, this equation can be propagated in > time.  However, it is also possible to find the resulting geometries by > solving the stationary Eikonal equation > >   F(x) | gradient d(x) | = 0 > > first, whose solution d can be used to find the evolved geometries at > arbitrary times t >= 0.  d can be calculated numerically using the Fast > Marching method, as described, for instance, by Sethian.  I'm working on > a theoretical paper about this at the moment, but also have working > implementations already. > > I would be interested to polish my code and release it as free software > to Octave Forge if there is interest.  (Will have to ask my employer > (University of Graz) first for permission, but I think that should be ok.) > > What I have and could release: > > * Implementation of the Fast Marching method to solve the equation for d > given arbitrary F (need not be strictly positive or something like > this).  It works on structured (rectangular) grids of any dimension and > with the possibility to exclude certain grid points from the possible > domain. > > * Calculation of the level-set function for evolved domains based on > this.  I'm currently using this on a structured grid in two dimensions, > but I think the code should handle arbitrary dimensions just fine.  (Or > I can extend it to do so.) > > * Determining geometrical properties from the level-set function, > including a polygonal approximation of the boundary and calculation of a > triangle mesh for the described domain.  This works in 2D and my mesh > structure is currently a bit different from the one used in the msh and > fem-fenics packages, but it shouldn't be hard to rewrite the code to > generate meshes fitting to msh / fem-fenics. > > In the future, I may also work on allowing more general meshes (for > instance, finer where the boundary movements must be resolved, but > coarser in the interior for more efficient PDE solving), and can > maintain the package accordingly. > > Would you be interested in this package to be relased on Octave Forge, > or do you think it is not of general interest? > > Yours, > Daniel > > -- > http://www.domob.eu/> OpenPGP: 901C 5216 0537 1D2A F071  5A0E 4D94 6EED 04F7 CF52 > Namecoin: id/domob -> https://nameid.org/?name=domob> -- > Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz > To go: Mon-Pri > Very interesting! If you prepare a package and uploaded it somewhere I can check it and test the instalation. Best place would be bitbucket, github etc...
Open this post in threaded view
|

## Re: Package for level-set method?

 On 12/03/2014 14:28, Juan Pablo Carbajal wrote: > On Wed, Mar 12, 2014 at 1:28 PM, Daniel Kraft <[hidden email]> wrote: >> Hi all! >> >> For my PhD, I'm working on shape optimisation with the level-set method. >>   The basic idea here is to describe geometries / domains via a level-set >> function phi, such that the domain is given as the open set >> >>    { x | phi(x) < 0 }. >> >> By calculating the viscosity solutions of the level-set equation >> >>    phi_t(x, t) + F(x) | gradient phi(x, t) | = 0, >> >> one can perform "changes" of the geometry('s level-set function) that >> correspond to movement of the boundary in normal direction according to >> the given speed-field F. >> >> Using a proper discretisation scheme, this equation can be propagated in >> time.  However, it is also possible to find the resulting geometries by >> solving the stationary Eikonal equation >> >>    F(x) | gradient d(x) | = 0 >> >> first, whose solution d can be used to find the evolved geometries at >> arbitrary times t >= 0.  d can be calculated numerically using the Fast >> Marching method, as described, for instance, by Sethian.  I'm working on >> a theoretical paper about this at the moment, but also have working >> implementations already. >> >> I would be interested to polish my code and release it as free software >> to Octave Forge if there is interest.  (Will have to ask my employer >> (University of Graz) first for permission, but I think that should be ok.) >> >> What I have and could release: >> >> * Implementation of the Fast Marching method to solve the equation for d >> given arbitrary F (need not be strictly positive or something like >> this).  It works on structured (rectangular) grids of any dimension and >> with the possibility to exclude certain grid points from the possible >> domain. >> >> * Calculation of the level-set function for evolved domains based on >> this.  I'm currently using this on a structured grid in two dimensions, >> but I think the code should handle arbitrary dimensions just fine.  (Or >> I can extend it to do so.) >> >> * Determining geometrical properties from the level-set function, >> including a polygonal approximation of the boundary and calculation of a >> triangle mesh for the described domain.  This works in 2D and my mesh >> structure is currently a bit different from the one used in the msh and >> fem-fenics packages, but it shouldn't be hard to rewrite the code to >> generate meshes fitting to msh / fem-fenics. >> >> In the future, I may also work on allowing more general meshes (for >> instance, finer where the boundary movements must be resolved, but >> coarser in the interior for more efficient PDE solving), and can >> maintain the package accordingly. >> >> Would you be interested in this package to be relased on Octave Forge, >> or do you think it is not of general interest? >> >> Yours, >> Daniel >> >> -- >> http://www.domob.eu/>> OpenPGP: 901C 5216 0537 1D2A F071  5A0E 4D94 6EED 04F7 CF52 >> Namecoin: id/domob -> https://nameid.org/?name=domob>> -- >> Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz >> To go: Mon-Pri >> > Very interesting! > > If you prepare a package and uploaded it somewhere I can check it and > test the instalation. Best place would be bitbucket, github etc... I agree : level-set methods are useful and can serve many purposes. Having them in Octave would be great. There is a Matlab toolbox for levet-set methods Ian Mitchell http://www.cs.ubc.ca/~mitchell/ToolboxLS  but unfortunately the licence is not compatible with the GPL.
Open this post in threaded view
|

## Re: Package for level-set method?

 Hi! On 2014-03-12 14:37, Julien Bect wrote: > On 12/03/2014 14:28, Juan Pablo Carbajal wrote: >> Very interesting! >> >> If you prepare a package and uploaded it somewhere I can check it and >> test the instalation. Best place would be bitbucket, github etc... > > I agree : level-set methods are useful and can serve many purposes. > Having them in Octave would be great. > > There is a Matlab toolbox for levet-set methods Ian Mitchell > > http://www.cs.ubc.ca/~mitchell/ToolboxLS  > > > but unfortunately the licence is not compatible with the GPL. Thanks for the quick feed-back!  I'm not yet ready to have a package immediately, wanted to gauge interest first.  (But the code is all there and works, just needs packaging and polishing.) Note, though, that my package won't even get close to the Toolbox linked to above as far as I can tell, it only includes some basic methods for evolution and geometry.  It also supports just the level-set equation mentioned in the OP that can be used to shape optimisation (and other things like active contours), not things like mean-curvature flow.  (But of course, we can start small and extend it later.) However, it seems as if my method of calculation based on the Eikonal equation with Fast Marching is different from what the Toolbox does (time stepping, but I've only looked at the manual very quickly).  I've not much experience with time stepping for the LSE, but my impression is that my approach is more efficient and also robust (but it only works for specific equations, or at least, I know that it works for my situation but know nothing about others). But nevertheless, it seems there's interest, so I will ask about permission to release the code freely and try to provide a test package as soon as possible. :) Yours, Daniel -- http://www.domob.eu/OpenPGP: 901C 5216 0537 1D2A F071  5A0E 4D94 6EED 04F7 CF52 Namecoin: id/domob -> https://nameid.org/?name=domob-- Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz To go: Mon-Pri smime.p7s (5K) Download Attachment
Open this post in threaded view
|

## Re: Package for level-set method?

Open this post in threaded view
|

## Re: Package for level-set method?

 In reply to this post by Juan Pablo Carbajal-2 Hi! On 2014-03-12 14:28, Juan Pablo Carbajal wrote: > Very interesting! > > If you prepare a package and uploaded it somewhere I can check it and > test the instalation. Best place would be bitbucket, github etc... Finally, I can come back to your offer.  I've got the permission (and actually, obligation) to publish the code under GPLv3 now from my university. For now, it is hosted on my own server, and can be checked out via   git clone http://git.domob.eu/levelset.gitSince this is the first time I tried to create a package, it would be cool if you or anyone else would look over it and check if I did everything correctly. I tried to annotate all functions extensively with help texts, tests and demos.  As you can see in the TODO file, I'm planning to also move my code for building triangle meshes (I'll use the msh package format) over to the package.  This should give a relatively complete toolbox for working with level-sets for various kinds of problems.  (Also, the fastmarching and ls_signed_distance routines may be handy in more general circumstances.) If it looks good, what do I have to do to get this accepted into Octave Forge?  I'll stick around as maintainer, as this is a core part of my own research code. When the package is integrated into Octave Forge, I can gladly write a Wiki page with examples and descriptions in addition to the demos present in the code (or presenting them with more explanations). Thank you very much!  Yours, Daniel -- http://www.domob.eu/OpenPGP: 901C 5216 0537 1D2A F071  5A0E 4D94 6EED 04F7 CF52 Namecoin: id/domob -> https://nameid.org/?name=domob-- Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz To go: Mon-Pri
Open this post in threaded view
|

## Re: Package for level-set method?

 On Mon, May 5, 2014 at 9:59 AM, Daniel Kraft <[hidden email]> wrote: > Hi! > > On 2014-03-12 14:28, Juan Pablo Carbajal wrote: >> Very interesting! >> >> If you prepare a package and uploaded it somewhere I can check it and >> test the instalation. Best place would be bitbucket, github etc... > > Finally, I can come back to your offer.  I've got the permission (and > actually, obligation) to publish the code under GPLv3 now from my > university. > > For now, it is hosted on my own server, and can be checked out via > >   git clone http://git.domob.eu/levelset.git> > Since this is the first time I tried to create a package, it would be > cool if you or anyone else would look over it and check if I did > everything correctly. > > I tried to annotate all functions extensively with help texts, tests and > demos.  As you can see in the TODO file, I'm planning to also move my > code for building triangle meshes (I'll use the msh package format) over > to the package.  This should give a relatively complete toolbox for > working with level-sets for various kinds of problems.  (Also, the > fastmarching and ls_signed_distance routines may be handy in more > general circumstances.) > > If it looks good, what do I have to do to get this accepted into Octave > Forge?  I'll stick around as maintainer, as this is a core part of my > own research code. > > When the package is integrated into Octave Forge, I can gladly write a > Wiki page with examples and descriptions in addition to the demos > present in the code (or presenting them with more explanations). > > Thank you very much!  Yours, > Daniel > > -- > http://www.domob.eu/> OpenPGP: 901C 5216 0537 1D2A F071  5A0E 4D94 6EED 04F7 CF52 > Namecoin: id/domob -> https://nameid.org/?name=domob> -- > Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz > To go: Mon-Pri Hi Daniel, The package looks good. I think when you have polish it a little bit (see below) is ready to be integrated into Octave Forge (@Carnë?) Here my observations - What is __levelset_getdir.m for? If it is a private function you should install it inside the private folder. - The scripts in the repository demoAll and testAll fail in several cases. Some demos and tests cant find the functions geomElements, internal_init_narrowband and internal_fastmarching. I guess is just old names for functions you have in your package. Cheers
Open this post in threaded view
|

## Re: Package for level-set method?

 Hi! On 2014-05-09 01:43, Juan Pablo Carbajal wrote: > The package looks good. I think when you have polish it a little bit > (see below) is ready to be integrated into Octave Forge (@Carnë?) Thank you very much for taking a look! It would be great to have it in Octave Forge -- there are still some things I want to improve over time (in particular, adding mesh building capabilities), but I'd prefer to get it into Octave Forge as soon as possible and then develop there further. > Here my observations > - What is __levelset_getdir.m for? If it is a private function you > should install it inside the private folder. It is a private function, but it is used in a demo.  (To locate the "maze.png" file.)  As such, I think I can not move it to "private/", since this seems not to be accessible from demos.  I found no better way of locating the image file from within the demo, but if you have suggestions, I'm open to change this. > - The scripts in the repository demoAll and testAll fail in several > cases. Some demos and tests cant find the functions geomElements, > internal_init_narrowband and internal_fastmarching. I guess is just > old names for functions you have in your package. These functions should all be provided by the .oct files in src.  Did you build them before running the demoAll and testAll scripts? A single test is currently xfail'ed (related to the first issue in the TODO file), but this is not a defect with respect to the functionality.  (Rather, a temporary and undocumented extension which I need to work around the problem in my own codes until I find the time to properly improve the code in the package to make the workaround unnecessary.) Everything else should work and all tests succeed. Yours, Daniel -- http://www.domob.eu/OpenPGP: 901C 5216 0537 1D2A F071  5A0E 4D94 6EED 04F7 CF52 Namecoin: id/domob -> https://nameid.org/?name=domob-- Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz To go: Mon-Pri smime.p7s (5K) Download Attachment
Open this post in threaded view
|

## Re: Package for level-set method?

 On Fri, May 9, 2014 at 8:25 AM, Daniel Kraft <[hidden email]> wrote: > Hi! > > On 2014-05-09 01:43, Juan Pablo Carbajal wrote: >> The package looks good. I think when you have polish it a little bit >> (see below) is ready to be integrated into Octave Forge (@Carnë?) > > Thank you very much for taking a look! > > It would be great to have it in Octave Forge -- there are still some > things I want to improve over time (in particular, adding mesh building > capabilities), but I'd prefer to get it into Octave Forge as soon as > possible and then develop there further. > >> Here my observations >> - What is __levelset_getdir.m for? If it is a private function you >> should install it inside the private folder. > > It is a private function, but it is used in a demo.  (To locate the > "maze.png" file.)  As such, I think I can not move it to "private/", > since this seems not to be accessible from demos.  I found no better way > of locating the image file from within the demo, but if you have > suggestions, I'm open to change this. > If it is a private function, why is a demo trying to call it directly? A private function should be called only from within other functions. Do you mean that functions cannot reach it? >> - The scripts in the repository demoAll and testAll fail in several >> cases. Some demos and tests cant find the functions geomElements, >> internal_init_narrowband and internal_fastmarching. I guess is just >> old names for functions you have in your package. > > These functions should all be provided by the .oct files in src.  Did > you build them before running the demoAll and testAll scripts? > > A single test is currently xfail'ed (related to the first issue in the > TODO file), but this is not a defect with respect to the functionality. >  (Rather, a temporary and undocumented extension which I need to work > around the problem in my own codes until I find the time to properly > improve the code in the package to make the workaround unnecessary.) > Everything else should work and all tests succeed. > I run "build.sh"  this created a tar file that I installed using "pkg". The compilation should be taken care by the Makefile. The problem is that your Makefile interferes with pkg install. From the phony argument "oct" remove all commands. That is you should have oct: \$(OCT_FILES) and nothing else. The compiled functions do not go to "private" they receive their own architecture dependent folder. Also remove the file FILES from the src folder. This made a correct installation of your package and everything works fine. > Yours, > Daniel > > -- > http://www.domob.eu/> OpenPGP: 901C 5216 0537 1D2A F071  5A0E 4D94 6EED 04F7 CF52 > Namecoin: id/domob -> https://nameid.org/?name=domob> -- > Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz > To go: Mon-Pri >
Open this post in threaded view
|

## Re: Package for level-set method?

 Hi! On 2014-05-09 11:44, Juan Pablo Carbajal wrote: > I run "build.sh"  this created a tar file that I installed using > "pkg". The compilation should be taken care by the Makefile. > The problem is that your Makefile interferes with pkg install. > From the phony argument "oct" remove all commands. That is you should have > oct: \$(OCT_FILES) > > and nothing else. The compiled functions do not go to "private" they > receive their own architecture dependent folder. > Also remove the file FILES from the src folder. Thanks for the hints! The point is that I want the compiled functions to be private to the package -- I don't care if they actually are in "private" or in an architecture-dependent folder.  But as I understand it, the default architecture-dependent folder is public, right? Can I also make it so that the .oct files (or some of them) are private to the package?  How do I achieve this? Yours, Daniel -- http://www.domob.eu/OpenPGP: 901C 5216 0537 1D2A F071  5A0E 4D94 6EED 04F7 CF52 Namecoin: id/domob -> https://nameid.org/?name=domob-- Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz To go: Mon-Pri smime.p7s (5K) Download Attachment
Open this post in threaded view
|

## Re: Package for level-set method?

 In reply to this post by Juan Pablo Carbajal-2 On 2014-05-09 11:44, Juan Pablo Carbajal wrote: > I run "build.sh"  this created a tar file that I installed using > "pkg". The compilation should be taken care by the Makefile. > The problem is that your Makefile interferes with pkg install. > From the phony argument "oct" remove all commands. That is you should have > oct: \$(OCT_FILES) > > and nothing else. The compiled functions do not go to "private" they > receive their own architecture dependent folder. > Also remove the file FILES from the src folder. > > This made a correct installation of your package and everything works fine. BTW, on my systems (one with Ubuntu 12.10 and one with Debian Wheezy), "pkg install" of the created file works just fine. Yours, Daniel -- http://www.domob.eu/OpenPGP: 901C 5216 0537 1D2A F071  5A0E 4D94 6EED 04F7 CF52 Namecoin: id/domob -> https://nameid.org/?name=domob-- Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz To go: Mon-Pri smime.p7s (5K) Download Attachment
Open this post in threaded view
|

## Re: Package for level-set method?

 On Fri, May 9, 2014 at 12:13 PM, Daniel Kraft <[hidden email]> wrote: > On 2014-05-09 11:44, Juan Pablo Carbajal wrote: >> I run "build.sh"  this created a tar file that I installed using >> "pkg". The compilation should be taken care by the Makefile. >> The problem is that your Makefile interferes with pkg install. >> From the phony argument "oct" remove all commands. That is you should have >> oct: \$(OCT_FILES) >> >> and nothing else. The compiled functions do not go to "private" they >> receive their own architecture dependent folder. >> Also remove the file FILES from the src folder. >> >> This made a correct installation of your package and everything works fine. > > BTW, on my systems (one with Ubuntu 12.10 and one with Debian Wheezy), > "pkg install" of the created file works just fine. > > Yours, > Daniel > > -- > http://www.domob.eu/> OpenPGP: 901C 5216 0537 1D2A F071  5A0E 4D94 6EED 04F7 CF52 > Namecoin: id/domob -> https://nameid.org/?name=domob> -- > Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz > To go: Mon-Pri > Have you try running the demoAll, making sure you removed all the added paths? It is failing here unless you let "pkg install" do its job. Let me find out if architecture dependent files can be private. In any case you should not be copying them manually, please remove the copy commands from the oct rule in the Makefile
Open this post in threaded view
|

## Re: Package for level-set method?

 In reply to this post by Juan Pablo Carbajal-2 Hi! On 2014-05-09 11:44, Juan Pablo Carbajal wrote: > On Fri, May 9, 2014 at 8:25 AM, Daniel Kraft <[hidden email]> wrote: >>> Here my observations >>> - What is __levelset_getdir.m for? If it is a private function you >>> should install it inside the private folder. >> >> It is a private function, but it is used in a demo.  (To locate the >> "maze.png" file.)  As such, I think I can not move it to "private/", >> since this seems not to be accessible from demos.  I found no better way >> of locating the image file from within the demo, but if you have >> suggestions, I'm open to change this. >> > > If it is a private function, why is a demo trying to call it directly? > A private function should be called only from within other functions. > Do you mean that functions cannot reach it? What I'm trying to achieve is this:  For the demo, I need an example image file to process (maze.png).  However, when this file is installed in the package directory, I need to find out where exactly this is in order to read the file successfully. The "best" way to do that I found so far is to use mfilename() from a function in the package directory (where also maze.png is installed). This function is __levelset_getdir. But if you know a better way to locate and read maze.png from within the demo, please let me know.  I could of course ask the user to enter the path to one of their own image files, but I think this makes the demo too tedious as an example. Yours, Daniel -- http://www.domob.eu/OpenPGP: 901C 5216 0537 1D2A F071  5A0E 4D94 6EED 04F7 CF52 Namecoin: id/domob -> https://nameid.org/?name=domob-- Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz To go: Mon-Pri smime.p7s (5K) Download Attachment
Open this post in threaded view
|

## Re: Package for level-set method?

 On 09/05/2014 11:18, Daniel Kraft wrote: > Hi! > > On 2014-05-09 11:44, Juan Pablo Carbajal wrote: >> On Fri, May 9, 2014 at 8:25 AM, Daniel Kraft <[hidden email]> wrote: > > The "best" way to do that I found so far is to use mfilename() from a > function in the package directory (where also maze.png is installed). > This function is __levelset_getdir. > > But if you know a better way to locate and read maze.png from within the > demo, please let me know.  I could of course ask the user to enter the > path to one of their own image files, but I think this makes the demo > too tedious as an example. > > Yours, > Daniel > how about fullfile(fileparts (which('an_m_file_in_the_dir.m'), 'maze.png')) or something like this I often put a function in directories of interest like below for similar reasons: function path = linearmachinerootdir()      path = getmfilepath(mfilename); end where getmfilepath. is just function filepath = getmfilepath(mfile) % getmfilepath: gets the directory containing an mfile % % Syntax % % filepath = getmfilepath(mfile) % % Input % % mfile is a string containing the name of the mfile for which the % location is to be found, the .m extension is optional % % Output % % filepath is the directory path containing the specified mfile %      if exist(mfile, 'file') == 2         filepath = fileparts(which(mfile));      else          error('UTILS:nofile', 'm-file does not appear to exist')      end end -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
Open this post in threaded view
|

## Re: Package for level-set method?

 In reply to this post by Daniel Kraft-2 On 9 May 2014 07:25, Daniel Kraft <[hidden email]> wrote: > Hi! > > On 2014-05-09 01:43, Juan Pablo Carbajal wrote: >> The package looks good. I think when you have polish it a little bit >> (see below) is ready to be integrated into Octave Forge (@Carnë?) > > Thank you very much for taking a look! > > It would be great to have it in Octave Forge -- there are still some > things I want to improve over time (in particular, adding mesh building > capabilities), but I'd prefer to get it into Octave Forge as soon as > possible and then develop there further. We can add it to Octave Forge no problem. To be released in the Octave Forge website there are a few requirements, one of them being that we have a clone of the repo in our servers. Also, we do not force a specific VCS (but we limit the choice to a distributed VCS) but there is a strong bias in favour of hg in Octave. With the exception of ltfat (which is a larger project on its own and developed elsewhere), all packages are in hg or in the process of moving to hg. Carnë
Open this post in threaded view
|

## Re: Package for level-set method?

 Hi! On 2014-05-09 12:47, Carnë Draug wrote: > On 9 May 2014 07:25, Daniel Kraft <[hidden email]> wrote: >> It would be great to have it in Octave Forge -- there are still some >> things I want to improve over time (in particular, adding mesh building >> capabilities), but I'd prefer to get it into Octave Forge as soon as >> possible and then develop there further. > > We can add it to Octave Forge no problem. To be released in the Octave > Forge website there are a few requirements, one of them being that we > have a clone of the repo in our servers. I'm fine with that.  In particular, I'd even like to get the "official" repo to Octave Forge, which is surely better than on my private server.  With "our servers", do you mean Sourceforge?  Or is the Sourceforge project just a "mirror"? > Also, we do not force a specific VCS (but we limit the choice to a > distributed VCS) but there is a strong bias in favour of hg in Octave. > With the exception of ltfat (which is a larger project on its own and > developed elsewhere), all packages are in hg or in the process of > moving to hg. As I've just migrated my own things from SVN to Git and am starting to feel comfortable with Git, I'd prefer to use Git if possible -- but if you want to have hg, I'd rather use hg than to have the repository not included with the rest. Yours, Daniel -- http://www.domob.eu/OpenPGP: 901C 5216 0537 1D2A F071  5A0E 4D94 6EED 04F7 CF52 Namecoin: id/domob -> https://nameid.org/?name=domob-- Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz To go: Mon-Pri smime.p7s (5K) Download Attachment
Open this post in threaded view
|

## Re: Package for level-set method?

 In reply to this post by Richard Crozier On Fri, May 9, 2014 at 12:28 PM, Richard Crozier <[hidden email]> wrote: > On 09/05/2014 11:18, Daniel Kraft wrote: >> >> Hi! >> >> On 2014-05-09 11:44, Juan Pablo Carbajal wrote: >>> >>> On Fri, May 9, 2014 at 8:25 AM, Daniel Kraft <[hidden email]> >>> wrote: > > >> >> The "best" way to do that I found so far is to use mfilename() from a >> function in the package directory (where also maze.png is installed). >> This function is __levelset_getdir. >> >> But if you know a better way to locate and read maze.png from within the >> demo, please let me know.  I could of course ask the user to enter the >> path to one of their own image files, but I think this makes the demo >> too tedious as an example. Richard's answer is a solution, you can go system specific by doing # Option 1 installed_pkgs_lst = pkg("list"); pkg_folder = installed_pkgs_lst (cellfun(@(x) ismember (x.name, {"level-set"}), installed_pkgs_lst, "unif", true)){1}.dir # Option 2 #pkg_data = pkg ("describe","level-set"){1}; #pkg_name = [pkg_data.name "-" pkg_data.version]; #pkg_folder = fullfile (pkg("prefix") , pkg_name) imgfile = fullfile (pkg_folder,"maze.png"); Option 1 is probably the safest. You can check existence with function "exists" >> >> Yours, >> Daniel >> > > how about > > fullfile(fileparts (which('an_m_file_in_the_dir.m'), 'maze.png')) > > or something like this > > I often put a function in directories of interest like below for similar > reasons: > > function path = linearmachinerootdir() > >     path = getmfilepath(mfilename); > > end > > > > where getmfilepath. is just > > > > function filepath = getmfilepath(mfile) > % getmfilepath: gets the directory containing an mfile > % > % Syntax > % > % filepath = getmfilepath(mfile) > % > % Input > % > % mfile is a string containing the name of the mfile for which the > % location is to be found, the .m extension is optional > % > % Output > % > % filepath is the directory path containing the specified mfile > % > >     if exist(mfile, 'file') == 2 > >        filepath = fileparts(which(mfile)); > >     else >         error('UTILS:nofile', 'm-file does not appear to exist') >     end > > end > > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. >
Open this post in threaded view
|

## Re: Package for level-set method?

 Hi! On 2014-05-09 14:02, Juan Pablo Carbajal wrote: > Richard's answer is a solution, you can go system specific by doing > # Option 1 > installed_pkgs_lst = pkg("list"); > pkg_folder = installed_pkgs_lst (cellfun(@(x) ismember (x.name, > {"level-set"}), installed_pkgs_lst, "unif", true)){1}.dir > > # Option 2 > #pkg_data = pkg ("describe","level-set"){1}; > #pkg_name = [pkg_data.name "-" pkg_data.version]; > #pkg_folder = fullfile (pkg("prefix") , pkg_name) > > imgfile = fullfile (pkg_folder,"maze.png"); > > Option 1 is probably the safest. You can check existence with function "exists" Honestly, this still seems very complicated for a seemingly trivial task (supplying example data files for demos).  But I've now rewritten the code to use option 1 (although with a loop to make it easier to read) and removed the __levelset_getdir function entirely. As I see it, the remaining issue to fix is now the internal files.  I've left the Makefile untouched for now.  But when you know whether or not private architecture-dependent functions are possible, I will either a) use them if they are, b) rename the files to __levelset_-names to keep them "private" even if this is not actually possible but get rid of the Makefile hack. Is this a good solution? BTW, I won't be available from now until Monday, but will try to resolve this issue then. Thank you very much for your help! Yours, Daniel -- http://www.domob.eu/OpenPGP: 901C 5216 0537 1D2A F071  5A0E 4D94 6EED 04F7 CF52 Namecoin: id/domob -> https://nameid.org/?name=domob-- Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz To go: Mon-Pri smime.p7s (5K) Download Attachment
Open this post in threaded view
|

## Re: Package for level-set method?

 Le 09/05/2014 14:22, Daniel Kraft a écrit : > As I see it, the remaining issue to fix is now the internal files.  I've > left the Makefile untouched for now.  But when you know whether or not > private architecture-dependent functions are possible, Hello Daniel, If I understand the issue correctly, I had the same question recently, and I was told that you cannot have architecture dependent files in private directories. http://octave.1599824.n4.nabble.com/Requirements-for-releasing-the-STK-toolbox-as-an-Octave-forge-package-tp4661779p4662249.html@++ Julien