🚀 go-pugleaf

In article <1992Dec23.011833.10963@vax.oxford.ac.uk>, leep@vax.oxford.ac.uk writes:
|> 
|> IsosurfaceLat and IsosurfaceLat2 both crash
|> on large data sets.  The size is not
|> always the ssame for the lattice, but instead seems
|> to be a function of the complexity of the surfaces
|> generated.  The limit for a lattice of char variables
|> is about 1.5M, at which point the helpful error
|> "segmentation fault" is generated and all other
|> modules hang.  Is this a known bug?  Is there a fix?
|> The isosurflat2 was pulled from swedishchief on Dec.22.
|> 
|> Is there any pd source available for the marching cubes
|> algorithm so that I can try and generate the iso-surfaces
|> external to explorer?
|> 
|> Cheers,
|> Peter Lee

Something to check for - does your arenasize exceed the available disk space
on the disk specified by tempdir (default is /usr/tmp).  The shared memory
arena used by explorer is mapped to a file under the tempdir directory.
This mapped file acts as the VM swapfile for the arena (not your swap
partition).

The mapped arena file does not start out attempting to use all of the
disk space specified by arenasize.  As memory is needed, the arena file
will grow.  If it grows past the available memory, weird execution
behavior will occur and no errors that the arena has grown larger than
the available disk space will be displayed.  I've encountered the kind of
weird behavior like you are seeing in the circumstances that I had specified
an arena larger than the disk space that I had.   I don't know if this is
the problem that you are encountering.

						--- Dave

-- 

    __   * __   _  __  ___			
   /  \ / / /  / \/  \/   \ 	He was a man like any other man, however, not
  /    /  \/  /  /\  /    /	quite like any other man.
  \___/\__/\_/  /_/ / \__/	
	           *		

In article <1992Dec24.004917.1397@odin.corp.sgi.com>, ciemo@bananapc.csd.sgi.com (Dave Ciemiewicz) writes:
> In article <1992Dec23.011833.10963@vax.oxford.ac.uk>, leep@vax.oxford.ac.uk writes:
> |> 
> |> IsosurfaceLat and IsosurfaceLat2 both crash
> |> on large data sets.  The size is not
> > ...
> |> Peter Lee
> 
> Something to check for - does your arenasize exceed the available disk space
> on the disk specified by tempdir (default is /usr/tmp).  The shared memory
> arena used by explorer is mapped to a file under the tempdir directory.
> This mapped file acts as the VM swapfile for the arena (not your swap
> partition).
> 
> The mapped arena file does not start out attempting to use all of the
> disk space specified by arenasize.  As memory is needed, the arena file
> will grow.  If it grows past the available memory, weird execution
> behavior will occur and no errors that the arena has grown larger than
> the available disk space will be displayed.  I've encountered the kind of
> weird behavior like you are seeing in the circumstances that I had specified
> an arena larger than the disk space that I had.   I don't know if this is
> the problem that you are encountering.
> 
> 						--- Dave


Thanks, this was the problem.   

However, on the machine I was using most of the disk is full
so I set the tempdir to a NSF mounted disk.  When I did this
none of my datascribe modules would work unless tempdir was
on a local disk.   Any ideas on what is wrong?  

cheers,
peter lee

In article <1992Dec24.161137.10995@vax.oxford.ac.uk>, leep@vax.oxford.ac.uk writes:

> However, on the machine I was using most of the disk is full
> so I set the tempdir to a NSF mounted disk.  When I did this
> none of my datascribe modules would work unless tempdir was
> on a local disk.   Any ideas on what is wrong?  
> 

   IRIX arena's don't particularly like working across NFS mounted
   filesystems.  There are possible data syncronization problems since
   it takes much longer to get the data to disk.  See the man page for
   usinit(3P) ( about the middle of the page ) for more information.

   One thing you might try.  If the other machine in the picture is also
   an SGI with explorer installed on it, you could set your DISPLAY 
   environment variable to you local machine, and run explorer on the
   other machine, with your data sets NFS mounted.  Just a thought.

Thanx,
Dave

  ---------------------------------------------------------------------------

   Dave Shreiner                                        <shreiner@sgi.com>
   Silicon Graphics, Inc.                                (415) 390 - 5063

  "There's never time to say all the things we need to say" - Fates Warning