memory use, 32 bit Linux system, version 2014.10.02
Here is the slightly modified code (I haven't done that re factoring yet,
will do tommorrow).
echo(version=version());
t_len = 420;
seg_h = 6; //6mm tall ring segment
base = seg_h/2; //get back to zero on Z axis
ID = 48; //main tube ID
OD = 50; //main tube OD
h_cc = 6; //center-to-center perforation spacing
h_dia = 3; //perforation hole diameter
p_deg = 360/(PIOD/h_cc); //degrees between perf holes
n_rot = floor(PIOD/h_cc) -1; //inner loop count
fn1=72;
fn2=32;
//weird, but it does the job!
function O(cnt) = cnt*p_deg/2 ;
//rotate around the tube this much "extra" each ring segment along length
module perf_tube()
{
difference() {
translate( [0, 0, t_len/2] )
union() {
difference() {
cylinder(h = t_len, d=OD, $fn=fn1, center = true);
translate([0,0,-1]) // cleaner cut
cylinder(h = t_len+3, d=ID, $fn=fn1, center = true); // bit
bigger
}
}
for ( j = [0 : t_len/seg_h] ) {
translate( [0, 0, (j*seg_h) + base] )
for ( i = [ 0 : n_rot ] ) {
rotate( [90, 0, i*p_deg + O(j)] )
translate( [0, 0, (ID+OD)/4] )
cylinder(h = OD-ID+1, d = h_dia, $fn=fn2, center = true);
}
}
}
}
echo(n_rot=n_rot,t_len=t_len,seg_h=seg_h,t_len/seg_h*n_rot);
perf_tube();
The cleaner cut of the two cylinders removed coincident faces and helped a
bit. But F5 was still stuffed.
The figures in the above post were based on:
fn1=64;
fn2=16;
The above, with higher $fn, on 2014.12.04, F6 took 1h 28m and used 5.8GB!
(on my 4GB system so some swapping involved).
So, for OpenSCAD testing, I'm going to run 2014.03 with the larger $fn
values, as I suspect that memory increase is unexpected.
Do you want the STL?
In answer to your original question, yes you do want to go 64bit, and I'd
suggest min 8GB RAM if feasible. (I'm planning my upgrade ATM). 16GB doesn't
cost much these days. Ands get the fastest single core GHz (in as many cores
as you can afford).
Unless specifically shown otherwise above, my contribution is in the Public Domain; To the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. This work is published globally via the internet. :) Inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/
View this message in context: http://forum.openscad.org/memory-use-32-bit-Linux-system-version-2014-10-02-tp10374p10393.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
BTW Marius, Nohead, Les (I'm the Michael who introduced you to OpenSCAD BTW -
just changed email addresses), I've now got two emails (from Hophead & Les)
with the title of this post, which do not appear here in Nabble. So either
Nabble is not quite right or Nohead/Les your individual setting on this new
Nabble implementation need adjustment.
Unless specifically shown otherwise above, my contribution is in the Public Domain; To the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. This work is published globally via the internet. :) Inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/
View this message in context: http://forum.openscad.org/memory-use-32-bit-Linux-system-version-2014-10-02-tp10374p10394.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
See I got the email below, but it is not here on the Web forum.
Nophead wrote
I set $fn set to 16 for the small holes and the inner cylinder set to h =
t_len + 1 to make the ends clean. F5 works fine for me and is very fast.
F6 takes 5 hours and also works fine on my 32 bit XP system.
This is with version 2014, 2, 25.
Not sure what has happened to the forum I didn't change anything.
Note the new, post crash, forum has default user preferences, you may need
to check your settings.
Yeh I also did the -z/+z bit for the two cylinders difference, helped a bit,
but F5 still stuffed. I have 'average' GPU, and F5 GPU% is ~75% flat-lined
with a refresh rate of around 10 seconds, forever, nasty. (NVIDEA ION
Graphics)
Interim update:
The same higher $fn as above, with 2014.03, is now at 999/1000 for F6, and
has only used 2GB memory, so it looks like 2014.12.04 (and prob earlier)
have 250% memory consumption v's 2014.03.
Not good.
Standby for final result.
Unless specifically shown otherwise above, my contribution is in the Public Domain; To the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. This work is published globally via the internet. :) Inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/
View this message in context: http://forum.openscad.org/memory-use-32-bit-Linux-system-version-2014-10-02-tp10374p10398.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On 12/05/2014 08:20 PM, MichaelAtOz wrote:
wmartin wrote
ps: recommended version of openSCAD?
Current snapshot 2014.12.04 here http://www.openscad.org/downloads.html
, may have some features to handle memory better and performance is better
too.
I'm running Win 7/64 OpenSCAD 64bit, I used the 2014.03 Production Release.
With slightly modified code (incl somewhat lower $fn values), I just did a
t_len = 420, F6 (no F5) it took 2h 14m 38s, and used 1.55GB of memory. That
has 1750 holes and taxes OpenSCAD, F5 is useless and F6 takes a long time.
The export to STL took a few minutes and not much more memory.
Do you want this STL (ie a bit chunkier than yours but looks OK to me)?
I'm going to try refactoring to see if there is a better way.
So, first lesson is that 64bit makes the difference between crashing &
just taking a long time, I first tried this with the 2014.03 32bit release
and crashed, out of "usable" memory. I still suspect it is trashing the
heap...
I have found that I can make a 48mm long segment with the $fn=100
setting without crashing, using 2014.10.2 that I currently have installed,
so am looking at creating offset segments of this size & stacking them up
in MeshLab. I looked at the first segment in MeshLab and it looks fine.
Much appreciate your taking the time to fiddle with my code, I'm sure
I'll learn a few good tricks from looking at the results.
There doesn't appear to be a 32bit Linux version of 2014.12.04 binary,
looks like I need to build from source to try that. Which is ok...
Heh. I would have to pick a first project that is problematic itself!
-bill
Might be OT but if you would like your SCAD file rendered to STL and shown online, Libre3D has adapted to show it.
Note: SCAD files with library plugins aren't supported yet but coming soon :-)
Example below shows a SCAD will render and anyone can download as an SCAD or STL file. The other render is just an uploaded STL for example too.
http://libre3d.com/category/569/Hand-Tools/listings/803/Gutting-Tool.html
On December 6, 2014 11:40:50 AM EST, William W Martin wwm@wwmartin.net wrote:
On 12/05/2014 08:20 PM, MichaelAtOz wrote:
wmartin wrote
ps: recommended version of openSCAD?
Current snapshot 2014.12.04 here
, may have some features to handle memory better and performance is
better
too.
I'm running Win 7/64 OpenSCAD 64bit, I used the 2014.03 Production
Release.
With slightly modified code (incl somewhat lower $fn values), I just
did a
t_len = 420, F6 (no F5) it took 2h 14m 38s, and used 1.55GB of
memory. That
has 1750 holes and taxes OpenSCAD, F5 is useless and F6 takes a long
time.
The export to STL took a few minutes and not much more memory.
Do you want this STL (ie a bit chunkier than yours but looks OK to
me)?
I'm going to try refactoring to see if there is a better way.
So, first lesson is that 64bit makes the difference between crashing &
just taking a long time, I first tried this with the 2014.03 32bit
release
and crashed, out of "usable" memory. I still suspect it is trashing the
heap...
I have found that I can make a 48mm long segment with the $fn=100
setting without crashing, using 2014.10.2 that I currently have
installed,
so am looking at creating offset segments of this size & stacking them
up
in MeshLab. I looked at the first segment in MeshLab and it looks fine.
Much appreciate your taking the time to fiddle with my code, I'm sure
I'll learn a few good tricks from looking at the results.
There doesn't appear to be a 32bit Linux version of 2014.12.04 binary,
looks like I need to build from source to try that. Which is ok...
Heh. I would have to pick a first project that is problematic itself!
-bill
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Final result, 2014.03 with:
fn1=72;
fn2=32;
Took 3h 23m (no swapping) and 2.85GB.
v's on 2014.12.04, F6 took 1h 28m (some swapping to SSD) and used 5.8GB!
Double memory again...
Support wrote
I didn't need to know that such a tool exists...
Unless specifically shown otherwise above, my contribution is in the Public Domain; To the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. This work is published globally via the internet. :) Inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/
View this message in context: http://forum.openscad.org/memory-use-32-bit-Linux-system-version-2014-10-02-tp10374p10408.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Well, I have more time than memory to burn...the older release looks
better to me. Building in parts & combining is working, just a few more
segments to render and I will have my perforated tube created. MeshLab
is amazing!
On 12/06/2014 01:21 PM, MichaelAtOz wrote:
Final result, 2014.03 with:
fn1=72;
fn2=32;
Took 3h 23m (no swapping) and 2.85GB.
v's on 2014.12.04, F6 took 1h 28m (some swapping to SSD) and used 5.8GB!
Double memory again...
Support wrote
I didn't need to know that such a tool exists...
Unless specifically shown otherwise above, my contribution is in the Public Domain; To the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. This work is published globally via the internet. :) Inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/
View this message in context: http://forum.openscad.org/memory-use-32-bit-Linux-system-version-2014-10-02-tp10374p10408.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
The reason you got my email and the forum didn't is because I replied to
you instead of to all. It wasn't necessary to do reply all with the
previous mail list.
On 6 December 2014 at 11:14, MichaelAtOz oz.at.michael@gmail.com wrote:
See I got the email below, but it is not here on the Web forum.
Nophead wrote
I set $fn set to 16 for the small holes and the inner cylinder set to h =
t_len + 1 to make the ends clean. F5 works fine for me and is very fast.
F6 takes 5 hours and also works fine on my 32 bit XP system.
This is with version 2014, 2, 25.
Not sure what has happened to the forum I didn't change anything.
Note the new, post crash, forum has default user preferences, you may need
to check your settings.
Yeh I also did the -z/+z bit for the two cylinders difference, helped a
bit,
but F5 still stuffed. I have 'average' GPU, and F5 GPU% is ~75% flat-lined
with a refresh rate of around 10 seconds, forever, nasty. (NVIDEA ION
Graphics)
Interim update:
The same higher $fn as above, with 2014.03, is now at 999/1000 for F6, and
has only used 2GB memory, so it looks like 2014.12.04 (and prob earlier)
have 250% memory consumption v's 2014.03.
Not good.
Standby for final result.
Unless specifically shown otherwise above, my contribution is in the
Public Domain; To the extent possible under law, I have waived all
copyright and related or neighbouring rights to this work. This work is
published globally via the internet. :) Inclusion of works of previous
authors is not included in the above.
The TPP is no simple "trade agreement." Fight it!
http://www.ourfairdeal.org/
View this message in context:
http://forum.openscad.org/memory-use-32-bit-Linux-system-version-2014-10-02-tp10374p10398.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
It may be faster to build the tube in segments and join then in OpenScad as
well because the slow bit is the result of the for loop is unioned before
the difference.
On 6 December 2014 at 22:30, William W Martin wwm@wwmartin.net wrote:
Well, I have more time than memory to burn...the older release looks
better to me. Building in parts & combining is working, just a few more
segments to render and I will have my perforated tube created. MeshLab is
amazing!
On 12/06/2014 01:21 PM, MichaelAtOz wrote:
Final result, 2014.03 with:
fn1=72;
fn2=32;
Took 3h 23m (no swapping) and 2.85GB.
v's on 2014.12.04, F6 took 1h 28m (some swapping to SSD) and used 5.8GB!
Double memory again...
Support wrote
http://libre3d.com/category/569/Hand-Tools/listings/803/
Gutting-Tool.html
I didn't need to know that such a tool exists...
Unless specifically shown otherwise above, my contribution is in the
Public Domain; To the extent possible under law, I have waived all
copyright and related or neighbouring rights to this work. This work is
published globally via the internet. :) Inclusion of works of previous
authors is not included in the above.
The TPP is no simple "trade agreement." Fight it!
http://www.ourfairdeal.org/
View this message in context: http://forum.openscad.org/
memory-use-32-bit-Linux-system-version-2014-10-02-tp10374p10408.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Yes, I did that in an earlier version, but saw a pattern of missing
triangles at the join lines between segments. Just recently
got all the segments exported & into MeshLab, joined them all & dumped
out in .ply format. Hoping to play with SU2 a bit .
On 12/06/2014 02:58 PM, nop head wrote:
It may be faster to build the tube in segments and join then in
OpenScad as well because the slow bit is the result of the for loop is
unioned before the difference.
On 6 December 2014 at 22:30, William W Martin <wwm@wwmartin.net
mailto:wwm@wwmartin.net> wrote:
Well, I have more time than memory to burn...the older release
looks better to me. Building in parts & combining is working, just
a few more segments to render and I will have my perforated tube
created. MeshLab is amazing!
On 12/06/2014 01:21 PM, MichaelAtOz wrote:
Final result, 2014.03 with:
fn1=72;
fn2=32;
Took 3h 23m (no swapping) and 2.85GB.
v's on 2014.12.04, F6 took 1h 28m (some swapping to SSD) and
used 5.8GB!
Double memory again...
Support wrote
http://libre3d.com/category/569/Hand-Tools/listings/803/Gutting-Tool.html
I didn't need to know that such a tool exists...
-----
Unless specifically shown otherwise above, my contribution is
in the Public Domain; To the extent possible under law, I have
waived all copyright and related or neighbouring rights to
this work. This work is published globally via the internet.
:) Inclusion of works of previous authors is not included in
the above.
The TPP is no simple “trade agreement.” Fight it!
http://www.ourfairdeal.org/
--
View this message in context:
http://forum.openscad.org/memory-use-32-bit-Linux-system-version-2014-10-02-tp10374p10408.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org