Package for level-set method?

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Package for level-set method?

Daniel Kraft-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Package for level-set method?

Juan Pablo Carbajal-2
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...
Reply | Threaded
Open this post in threaded view
|

Re: Package for level-set method?

Julien Bect
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 
<http://www.cs.ubc.ca/%7Emitchell/ToolboxLS>

but unfortunately the licence is not compatible with the GPL.

Reply | Threaded
Open this post in threaded view
|

Re: Package for level-set method?

Daniel Kraft-2
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 
> <http://www.cs.ubc.ca/%7Emitchell/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
Reply | Threaded
Open this post in threaded view
|

Re: Package for level-set method?

Juan Pablo Carbajal-2
On Wed, Mar 12, 2014 at 2:50 PM, Daniel Kraft <[hidden email]> wrote:

> 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
>> <http://www.cs.ubc.ca/%7Emitchell/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
>

Good!
Some tips to save work later:
1. For functions that overlap with the Matlab toolbox (if it is an
official one), write compatible function signatures.
2. You can ask the developers of the package to release under gpl
compatible licenses. This has work very well in the past. You can
entice them with potential extended functionalities that your
functions can provide to the packages (only if they would release
under gpl compatible... :D).
http://wiki.octave.org/Asking_for_package_to_be_released_under_GPL:_examples
3. Write tests and demos!
4. In the documentation of your functions do not forget to cite papers
of books if you know them.
5. When you have something working do write a wiki page with examples
of use (you can even start there so we see how to use your package).
Example: http://wiki.octave.org/Geometry_package.
6. If you have publications using GNu Octave, please ad them there here
http://wiki.octave.org/Publications_using_Octave
Reply | Threaded
Open this post in threaded view
|

Re: Package for level-set method?

Daniel Kraft-2
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.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

Reply | Threaded
Open this post in threaded view
|

Re: Package for level-set method?

Juan Pablo Carbajal-2
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

Reply | Threaded
Open this post in threaded view
|

Re: Package for level-set method?

Daniel Kraft-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Package for level-set method?

Juan Pablo Carbajal-2
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
>

Reply | Threaded
Open this post in threaded view
|

Re: Package for level-set method?

Daniel Kraft-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Package for level-set method?

Daniel Kraft-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Package for level-set method?

Juan Pablo Carbajal-2
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

Reply | Threaded
Open this post in threaded view
|

Re: Package for level-set method?

Daniel Kraft-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Package for level-set method?

Richard Crozier
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.


Reply | Threaded
Open this post in threaded view
|

Re: Package for level-set method?

Carnë Draug
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ë

Reply | Threaded
Open this post in threaded view
|

Re: Package for level-set method?

Daniel Kraft-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Package for level-set method?

Juan Pablo Carbajal-2
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.
>

Reply | Threaded
Open this post in threaded view
|

Re: Package for level-set method?

Daniel Kraft-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Package for level-set method?

Julien Bect
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


Reply | Threaded
Open this post in threaded view
|

Re: Package for level-set method?

Juan Pablo Carbajal-2
In reply to this post by Daniel Kraft-2
On Fri, May 9, 2014 at 2:22 PM, Daniel Kraft <[hidden email]> wrote:
> 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

The issue with the hack it that it interferes with the standard
procedure we have to handle packages that compile functions. As it is
now, i.e. with the Makefile hack, it is not an Octave forge package,
because it fails when the user has its own "prefix" folder defined
(see pkg prefix option). You need to leave pkg handle the compiled
functions. We will see if we can make them private but for now just
let them go to the arch dependent folder and be public, just for now
(I see several packages using the "__" naming convention for private
compiled functions, so go ahead and do that for now!).

The issue with finding the folder is rather a missing feature of pkg.
It is implemented in new version, but we haven't merged it yet. In the
new version to get the folder of the package you just do

pkg ("describe","level-set"){1}.dir

Cheers

12