Menu
▾
▴
foam-extend-developers — Purpose of this list is to coordinate the efforts of those developing foam-extend. It is readable for the public but senders have to apply (criterion is at least one successful pull-request)
You can subscribe to this list here.
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(13) |
Nov
(11) |
Dec
(3) |
|---|
|
From: Martin B. <bea...@gm...> - 2015-12-18 05:11:12
|
Done. A merge request was submitted to the foam-extend project on SF.Net. By the way, I am activating this new feature for all of our foam-extend/OpenFOAM installations on our HPC supercomputer. In our case, the maximum number of cells before enforcing the 'binary' writeFormat will be 1, not 512. We are basically getting rid of any inadvertent usage of the 'ascii' writeFormat for all of our foam-extend/OpenFOAM simulations. Martin On Wed, Nov 25, 2015 at 10:25 AM, Martin Beaudoin <bea...@gm... > wrote: > > > On Wed, Nov 25, 2015 at 6:26 AM, Hrvoje Jasak <hrv...@fs...> wrote: > >> Why don't we force gzip instead - in my experience, this is smaller than >> binary. >> > > Good point. I guess we could offer a few compile-time options to tackle > this issue with more flexibility. > > Indeed, we often get smaller file size with gzip, but I would argue that > this is mainly because we are compressing ASCII-converted floating-point > values with a small number of significant digits (for example, the still > very common: writePrecision 6). > > My main issues with the ASCII writeFormat is of course the waste of > storage space, but also self-imposed loss of numerical resolution when > storing our solutions on disk. > > On one hand we are computing (quite often for weeks at a time on large > super-computers ) numerically sensitive algorithms using double precision > floating point values, but we only store 6 of 7 significant digits for our > intermediary or final results. This kind of resolution is fine for storing > meshes coordinates or for visualization purposes with paraView, but for > restarting a simulation from a set of solutions stored on disk, I am not so > sure about the impact of this loss of resolution on the first few > iterations. Would be nice to do an numerical analysis here on a broad set > of solvers. > > And doing post-processing of self-imposed low-resolution numerical values > while knowing that we threw away to the full double-precision information > in the first place has always troubled me a bit. > > As for the gzip option, if you offer me the choice between two > human-nonreadable file formats, binary vs ASCII gzipped, I will prefer > uncompressed binary, which offers me full numerical resolution, and without > wasting any CPU time doing compression. > > I think the ASCII writeFormat is very useful for learning or discovering > this simulation platform, and we should keep it. But when moving to the > realm of simulation of millions-cells problems, users usually do not > revisit this option, and data centers all over the world hosting Foam CFD > computations are suffering from this kind of user oversight, or need to do > a lot of users hand-holding. > > I am basically looking for a well-balanced option here, while working on a > possibly better solution HPC-wise... More about this later. > > Martin > > > >> >> I'd like to hear other opinions, but I am open to any good ideas >> >> HJ >> >> > On 25 Nov 2015, at 03:16, Martin Beaudoin <bea...@gm...> >> wrote: >> > >> > Hello, >> > >> > I am seriously considering disabling the ASCII writeFormat when meshes >> are larger than a predefined cells number. >> > >> > The idea is to still offer the ASCII writeFormat for small cases (which >> is useful for testing or training), but to mark it as unavailable when >> running simulations with serious size meshes, let's say larger than 10k >> cells. >> > >> > For larger meshes, the user would be forced to use the binary >> writeFormat. >> > >> > The specific mesh size would be defined at compile time, so site admins >> would be able to adjust this number if need be, but this number would not >> be overridable at runtime by users. >> > >> > The amount of storage space wasted on Foam/OpenFOAM meshes and >> solutions ASCII files is just too important. >> > >> > Thank you for your comments on this "radical" idea. >> > >> > Martin >> > >> > >> ------------------------------------------------------------------------------ >> > Go from Idea to Many App Stores Faster with Intel(R) XDK >> > Give your users amazing mobile app experiences with Intel(R) XDK. >> > Use one codebase in this all-in-one HTML5 development environment. >> > Design, debug & build mobile apps & 2D/3D high-impact games for >> multiple OSs. >> > http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140 >> > _______________________________________________ >> > Foam-extend-developers mailing list >> > Foa...@li... >> > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers >> >> >> ------------------------------------------------------------------------------ >> Go from Idea to Many App Stores Faster with Intel(R) XDK >> Give your users amazing mobile app experiences with Intel(R) XDK. >> Use one codebase in this all-in-one HTML5 development environment. >> Design, debug & build mobile apps & 2D/3D high-impact games for multiple >> OSs. >> http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140 >> _______________________________________________ >> Foam-extend-developers mailing list >> Foa...@li... >> https://lists.sourceforge.net/lists/listinfo/foam-extend-developers >> > > > > -- > Martin Beaudoin > -- Martin Beaudoin |
|
From: Martin B. <bea...@gm...> - 2015-12-05 19:01:20
|
The merge request is available. Enjoy. Martin On Thu, Dec 3, 2015 at 8:36 AM, Martin Beaudoin <bea...@gm...> wrote: > I've just completed a testHarness run on a Raspberry Pi2 using the > Raspbian OS, which is more "mainstream" for this kind of hardware. > > Foam ran as expected, with the failing tests related to either reaching > the 20min timeout, or simply running out of memory for some parallel runs. > > I will cleanup and document my changes, then I will propose a merge > request. > > Martin > > On Thu, Nov 26, 2015 at 9:32 AM, Martin Beaudoin < > bea...@gm...> wrote: > >> Indeed, a dirt cheap full-fledge Linux machine. >> >> Since it appears the processor of the Pi zero is very similar to the Pi 1 >> processor, I am pretty sure that Foam would work on this device too. I was >> able to compile and run foam-extend on my little Pi1 device prior to >> building my little Pi2 cluster. >> >> Not a whole lot of RAM (same as the Pi 1), but hey, you got already >> plenty for what you are paying for. >> >> I think reliable configurations are available to access this device >> though one of its USB port (either serial-over-USB or Ethernet-over-USB >> access), so we could have a relatively cheap 'Foam on a stick' solution for >> the workshop. >> >> The main US reseller of the Pi Zero is already out of stock for the bare >> bone device, so I guess people are already shopping for their Xmas >> stockings :) >> >> Martin >> >> >> >> On Thu, Nov 26, 2015 at 5:21 AM, Bernhard Gschaider <bgs...@ic...> >> wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> THAT looks exciting: https://www.raspberrypi.org/blog/raspberry-pi-zero/ >>> >>> Bernhard >>> >>> Am 29.10.15 um 06:31 schrieb Martin Beaudoin: >>> > >>> > On Wed, Oct 28, 2015 at 9:36 PM, Martin Beaudoin >>> > <bea...@gm... <mailto:bea...@gm...>> wrote: >>> > >>> > >>> > >>> > On Wed, Oct 28, 2015 at 7:45 PM, Bernhard Gschaider >>> > <bgs...@ic... <mailto:bgs...@ic...>> wrote: >>> > >>> > Am 29.10.15 um 00:12 schrieb Martin Beaudoin: >>> > >>> >> > As for using such small systems for the Workshop USB >>> > stick, if w >>> > e can >>> >> > figure out a way to USB tether a RaspBerry Pi2 with a >>> > normal lap >>> > top + >>> >> > some kind of terminal app. so we can simply ssh through >>> > the USB >>> > link, >>> >> > then we could have cheaper solution than the Intel stick. >>> >> > >>> >> > Here is a rough estimate of the cost in USD$, based on >>> > the units >>> > I have >>> >> > bought so far: >>> >> > >>> >> > * RaspBerry Pi 2 Model B : 35$ >>> >> > * 32GB Ultra MicroSDHC Class 10 card: 15$ >>> >> > * A Raspberry Pi2 case : 10$ >>> >> > * A USB cable for power and tether : 5$ >>> >> > >>> >> > For a total of roughly 65 $USD. >>> >> > >>> >> > And a 32GB card is slightly roomy. The OS is free, and >>> > the recip >>> > e to >>> >> > deploy foam-extend over this device is known. >>> >> > >>> >> > And we are still not talking bulk pricing here. I am >>> > sure we can >>> > shave a >>> >> > few $ if we buy a 100 of those... >>> >> > >>> >> > So the only piece of the puzzle remaining is a little >>> > bit of sof >>> > tware >>> >> > for USB tethering.... >>> >> > >>> >> > Maybe we can do all this as well with an Intel Compute >>> > stick. Bo >>> > th >>> >> > solutions would be way cool... >>> > >>> >> But the ultimate decision is of course with the Workshop >>> > organizer >>> > . >>> >> Because of course the logistics for the production of >>> > USB-keys is >>> >> already known >>> > >>> >> But lets see if we find something >>> > >>> > >>> >> Some other possible avenues to link a Pi2 with a good old >>> >> Linux/Mac/Windows laptop: >>> > >>> >> * Ethernet to Ethernet using an Ethernet crossover patch cable. >>> >> Needs an Ethernet port on the laptop, which no longer comes standa >>> > rd >>> >> on some laptops (MacBook Air) >>> >> Probably needs to add some kind of additional network routing to >>> >> make this work while the laptop is still connected to the OFW wifi >>> >> hotspot >>> > >>> > Something like this >>> > http://diyhacking.com/connect-raspberry-pi-to-laptop-display/ >>> > >>> > What is not funny here is that for every OS setting up the >>> > network is >>> > different (plus that some people might not have the privileges >>> > for this) >>> > >>> > >>> >> Yep, not an attractive solution for a whole group of various and >>> >> different platforms or OSes. >>> >> Too much time will be needed to set this up prior to starting the >>> >> trainings and such... >>> > >>> > >>> >> * Wifi access >>> >> We can transform the Pi2 as a Wifi Access point so the laptop can >>> >> establish a WIFI connection directly with the Pi2. >>> >> We need to add a decent WIFI USB dongle to the Pi2 (+ ~12 USD$) >>> >> Having a room full of 10s of little WIFI Access points/routers wou >>> > ld >>> >> be a very funny and probably inextricable mess >>> > >>> > And every RasPi would have to be setup differently so that it can be >>> > paired (otherwise Joe will connect to Abduhls RasPi) >>> > >>> > Note really feasible >>> > >>> > >>> >> Indeed. >>> > >>> > >>> > >>> >> * Serial over USB >>> >> The laptop would connect unidirectionally the Pi2 using an emulat >>> > ed >>> >> serial/terminal console available over one of the 4 USB ports >>> >> available on the Pi2 >>> >> Ohhhhhhh, maybe we have something worth exploring here too..... >>> >> Kermit anyone? LOL :):) >>> > >>> > >>> http://workshop.raspberrypiaustralia.com/usb/ttl/connecting/2014/08/31/0 >>> > 1-connecting-to-raspberry-pi-via-usb/ >>> > < >>> http://workshop.raspberrypiaustralia.com/usb/ttl/connecting/2014/08/31/01-connecting-to-raspberry-pi-via-usb/ >>> > >>> > >>> > Needs additional hardware and the correct cable >>> > >>> > >>> >> And we cannot run paraview over a mere ASCII console.... Not a >>> great >>> >> all around solution. >>> > >>> > >>> >> * TCP/IP over USB >>> >> Looks like we need a special kind of cable for this >>> >> Still investigating.... >>> > >>> >> But definitely, the USB port is probably the most universal connector >>> >> still available on a multitude of hardware platforms. Let's find a way >>> >> to talk to this little guy... >>> > >>> > I can't think of another way than the ones you listed. To be honest: >>> > none of them convinces me when I think of the support problems >>> > they're >>> > going to raise. But I'll keep looking >>> > >>> > >>> >> Yup, we need something easy to setup, and based on some really >>> >> common laptop applications like Putty or MobaXterm for Windows, >>> or X >>> >> Windows over ssh for OSX or Linux. The complexity of this setup >>> has >>> >> to remain on the Pi2 side so we can configure it correctly >>> ourselves >>> >> prior to distributing these little beast... >>> > >>> >> Going back hunting... >>> > >>> > >>> >> Looks like there is no way around it, a USB to USB connection >>> requires a >>> >> fancy USB Bridge cable with some electronics embedded in the cable. >>> >> Basically, USB cannot do host to host without this kind of device. See >>> >> here for the details : http://www.linux-usb.org/usbnet/ >>> > >>> >> So it looks to me the best and most flexible option now becomes using >>> >> the Pi2 Ethernet port + short Ethernet cable + Ethernet to USB >>> adapter. >>> > >>> >> I can find on Amazon some USB 2.0 to 10/100 Fast Ethernet LAN Wired >>> >> Network Adapter for about 20 $USD. >>> >> A short flat Ethernet cable can be bought for about 1$. >>> >> Still bearable. >>> > >>> >> For laptops having there own embedded Ethernet port, the Ethernet to >>> USB >>> >> adapter is not necessary, of course, but still remains convenient when >>> >> going back to the office and having to plug back into the wired >>> >> corporate network while still keeping connected with the Pi2. For >>> >> laptops like the MacBook Air lacking an embedded Ethernet port, such >>> >> Ethernet adapters would be necessary to connect to the Pi2 over >>> Ethernet. >>> > >>> >> So the challenge is now to find a simple Ethernet to Ethernet network >>> >> setup that will work for Windows, OSX and Linux. >>> >> Configuring the Pi2 to act as a local DHCP server for this Ethernet >>> link >>> >> might be a good starting point. >>> >> I already got a similar setup for my little Pi2 cluster. Let's try to >>> >> see if I can make this fly... >>> > >>> >> Martin >>> > >>> >> Martin >>> > >>> > >>> > Bernhard >>> > >>> > >>> > >>> >> Martin >>> > >>> > >>> > >>> >> Bernhard >>> > >>> > >>> >> > >>> >> > Martin >>> >> > >>> >> > >>> >> > >>> >> > >>> > >>> > ------------------------------------------------------------------ >>> > ------------ >>> >> > >>> >> > >>> >> > >>> >> > _______________________________________________ >>> >> > Foam-extend-developers mailing list >>> >> > Foa...@li... >>> > <mailto:Foa...@li...> >>> >> <mailto:Foa...@li... >>> > <mailto:Foa...@li...>> >>> >> > >>> > https://lists.sourceforge.net/lists/listinfo/foam-extend-develop >>> > ers >>> >> > >>> > >>> > >>> > ------------------------------------------------------------------ >>> > ------------ >>> >> _______________________________________________ >>> >> Foam-extend-developers mailing list >>> >> Foa...@li... >>> > <mailto:Foa...@li...> >>> >> <mailto:Foa...@li... >>> > <mailto:Foa...@li...>> >>> > >>> > https://lists.sourceforge.net/lists/listinfo/foam-extend-developer >>> > s >>> > >>> > >>> > >>> > >>> >> -- >>> >> Martin Beaudoin >>> > >>> > >>> > >>> > ---------------------------------------------------------------------- >>> > -------- >>> > >>> > >>> > >>> >> _______________________________________________ >>> >> Foam-extend-developers mailing list >>> >> Foa...@li... >>> > <mailto:Foa...@li...> >>> >> https://lists.sourceforge.net/lists/listinfo/foam-extend-developers >>> > >>> > >>> > >>> ------------------------------------------------------------------------------ >>> > _______________________________________________ >>> > Foam-extend-developers mailing list >>> > Foa...@li... >>> > <mailto:Foa...@li...> >>> > >>> https://lists.sourceforge.net/lists/listinfo/foam-extend-developers >>> > >>> > >>> > >>> > >>> > -- >>> > Martin Beaudoin >>> > >>> > >>> > >>> > >>> > -- >>> > Martin Beaudoin >>> > >>> > >>> > >>> ------------------------------------------------------------------------------ >>> > >>> > >>> > >>> > _______________________________________________ >>> > Foam-extend-developers mailing list >>> > Foa...@li... >>> > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers >>> > >>> -----BEGIN PGP SIGNATURE----- >>> Comment: GPGTools - https://gpgtools.org >>> >>> iEYEARECAAYFAlZW3R0ACgkQXIMfp1I+9MFEaQCfWD8axrfJs2JL2lhV4o4V0g1y >>> cr0AoMvgwY4fOdpwfzadrAjcLnDBJ5jw >>> =q9a3 >>> -----END PGP SIGNATURE----- >>> >>> >>> ------------------------------------------------------------------------------ >>> Go from Idea to Many App Stores Faster with Intel(R) XDK >>> Give your users amazing mobile app experiences with Intel(R) XDK. >>> Use one codebase in this all-in-one HTML5 development environment. >>> Design, debug & build mobile apps & 2D/3D high-impact games for multiple >>> OSs. >>> http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140 >>> _______________________________________________ >>> Foam-extend-developers mailing list >>> Foa...@li... >>> https://lists.sourceforge.net/lists/listinfo/foam-extend-developers >>> >> >> >> >> -- >> Martin Beaudoin >> > > > > -- > Martin Beaudoin > -- Martin Beaudoin |
|
From: Martin B. <bea...@gm...> - 2015-12-03 13:37:32
|
I've just completed a testHarness run on a Raspberry Pi2 using the Raspbian OS, which is more "mainstream" for this kind of hardware. Foam ran as expected, with the failing tests related to either reaching the 20min timeout, or simply running out of memory for some parallel runs. I will cleanup and document my changes, then I will propose a merge request. Martin On Thu, Nov 26, 2015 at 9:32 AM, Martin Beaudoin <bea...@gm...> wrote: > Indeed, a dirt cheap full-fledge Linux machine. > > Since it appears the processor of the Pi zero is very similar to the Pi 1 > processor, I am pretty sure that Foam would work on this device too. I was > able to compile and run foam-extend on my little Pi1 device prior to > building my little Pi2 cluster. > > Not a whole lot of RAM (same as the Pi 1), but hey, you got already plenty > for what you are paying for. > > I think reliable configurations are available to access this device though > one of its USB port (either serial-over-USB or Ethernet-over-USB access), > so we could have a relatively cheap 'Foam on a stick' solution for the > workshop. > > The main US reseller of the Pi Zero is already out of stock for the bare > bone device, so I guess people are already shopping for their Xmas > stockings :) > > Martin > > > > On Thu, Nov 26, 2015 at 5:21 AM, Bernhard Gschaider <bgs...@ic...> > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> THAT looks exciting: https://www.raspberrypi.org/blog/raspberry-pi-zero/ >> >> Bernhard >> >> Am 29.10.15 um 06:31 schrieb Martin Beaudoin: >> > >> > On Wed, Oct 28, 2015 at 9:36 PM, Martin Beaudoin >> > <bea...@gm... <mailto:bea...@gm...>> wrote: >> > >> > >> > >> > On Wed, Oct 28, 2015 at 7:45 PM, Bernhard Gschaider >> > <bgs...@ic... <mailto:bgs...@ic...>> wrote: >> > >> > Am 29.10.15 um 00:12 schrieb Martin Beaudoin: >> > >> >> > As for using such small systems for the Workshop USB >> > stick, if w >> > e can >> >> > figure out a way to USB tether a RaspBerry Pi2 with a >> > normal lap >> > top + >> >> > some kind of terminal app. so we can simply ssh through >> > the USB >> > link, >> >> > then we could have cheaper solution than the Intel stick. >> >> > >> >> > Here is a rough estimate of the cost in USD$, based on >> > the units >> > I have >> >> > bought so far: >> >> > >> >> > * RaspBerry Pi 2 Model B : 35$ >> >> > * 32GB Ultra MicroSDHC Class 10 card: 15$ >> >> > * A Raspberry Pi2 case : 10$ >> >> > * A USB cable for power and tether : 5$ >> >> > >> >> > For a total of roughly 65 $USD. >> >> > >> >> > And a 32GB card is slightly roomy. The OS is free, and >> > the recip >> > e to >> >> > deploy foam-extend over this device is known. >> >> > >> >> > And we are still not talking bulk pricing here. I am >> > sure we can >> > shave a >> >> > few $ if we buy a 100 of those... >> >> > >> >> > So the only piece of the puzzle remaining is a little >> > bit of sof >> > tware >> >> > for USB tethering.... >> >> > >> >> > Maybe we can do all this as well with an Intel Compute >> > stick. Bo >> > th >> >> > solutions would be way cool... >> > >> >> But the ultimate decision is of course with the Workshop >> > organizer >> > . >> >> Because of course the logistics for the production of >> > USB-keys is >> >> already known >> > >> >> But lets see if we find something >> > >> > >> >> Some other possible avenues to link a Pi2 with a good old >> >> Linux/Mac/Windows laptop: >> > >> >> * Ethernet to Ethernet using an Ethernet crossover patch cable. >> >> Needs an Ethernet port on the laptop, which no longer comes standa >> > rd >> >> on some laptops (MacBook Air) >> >> Probably needs to add some kind of additional network routing to >> >> make this work while the laptop is still connected to the OFW wifi >> >> hotspot >> > >> > Something like this >> > http://diyhacking.com/connect-raspberry-pi-to-laptop-display/ >> > >> > What is not funny here is that for every OS setting up the >> > network is >> > different (plus that some people might not have the privileges >> > for this) >> > >> > >> >> Yep, not an attractive solution for a whole group of various and >> >> different platforms or OSes. >> >> Too much time will be needed to set this up prior to starting the >> >> trainings and such... >> > >> > >> >> * Wifi access >> >> We can transform the Pi2 as a Wifi Access point so the laptop can >> >> establish a WIFI connection directly with the Pi2. >> >> We need to add a decent WIFI USB dongle to the Pi2 (+ ~12 USD$) >> >> Having a room full of 10s of little WIFI Access points/routers wou >> > ld >> >> be a very funny and probably inextricable mess >> > >> > And every RasPi would have to be setup differently so that it can be >> > paired (otherwise Joe will connect to Abduhls RasPi) >> > >> > Note really feasible >> > >> > >> >> Indeed. >> > >> > >> > >> >> * Serial over USB >> >> The laptop would connect unidirectionally the Pi2 using an emulat >> > ed >> >> serial/terminal console available over one of the 4 USB ports >> >> available on the Pi2 >> >> Ohhhhhhh, maybe we have something worth exploring here too..... >> >> Kermit anyone? LOL :):) >> > >> > >> http://workshop.raspberrypiaustralia.com/usb/ttl/connecting/2014/08/31/0 >> > 1-connecting-to-raspberry-pi-via-usb/ >> > < >> http://workshop.raspberrypiaustralia.com/usb/ttl/connecting/2014/08/31/01-connecting-to-raspberry-pi-via-usb/ >> > >> > >> > Needs additional hardware and the correct cable >> > >> > >> >> And we cannot run paraview over a mere ASCII console.... Not a >> great >> >> all around solution. >> > >> > >> >> * TCP/IP over USB >> >> Looks like we need a special kind of cable for this >> >> Still investigating.... >> > >> >> But definitely, the USB port is probably the most universal connector >> >> still available on a multitude of hardware platforms. Let's find a way >> >> to talk to this little guy... >> > >> > I can't think of another way than the ones you listed. To be honest: >> > none of them convinces me when I think of the support problems >> > they're >> > going to raise. But I'll keep looking >> > >> > >> >> Yup, we need something easy to setup, and based on some really >> >> common laptop applications like Putty or MobaXterm for Windows, or >> X >> >> Windows over ssh for OSX or Linux. The complexity of this setup has >> >> to remain on the Pi2 side so we can configure it correctly >> ourselves >> >> prior to distributing these little beast... >> > >> >> Going back hunting... >> > >> > >> >> Looks like there is no way around it, a USB to USB connection requires >> a >> >> fancy USB Bridge cable with some electronics embedded in the cable. >> >> Basically, USB cannot do host to host without this kind of device. See >> >> here for the details : http://www.linux-usb.org/usbnet/ >> > >> >> So it looks to me the best and most flexible option now becomes using >> >> the Pi2 Ethernet port + short Ethernet cable + Ethernet to USB adapter. >> > >> >> I can find on Amazon some USB 2.0 to 10/100 Fast Ethernet LAN Wired >> >> Network Adapter for about 20 $USD. >> >> A short flat Ethernet cable can be bought for about 1$. >> >> Still bearable. >> > >> >> For laptops having there own embedded Ethernet port, the Ethernet to >> USB >> >> adapter is not necessary, of course, but still remains convenient when >> >> going back to the office and having to plug back into the wired >> >> corporate network while still keeping connected with the Pi2. For >> >> laptops like the MacBook Air lacking an embedded Ethernet port, such >> >> Ethernet adapters would be necessary to connect to the Pi2 over >> Ethernet. >> > >> >> So the challenge is now to find a simple Ethernet to Ethernet network >> >> setup that will work for Windows, OSX and Linux. >> >> Configuring the Pi2 to act as a local DHCP server for this Ethernet >> link >> >> might be a good starting point. >> >> I already got a similar setup for my little Pi2 cluster. Let's try to >> >> see if I can make this fly... >> > >> >> Martin >> > >> >> Martin >> > >> > >> > Bernhard >> > >> > >> > >> >> Martin >> > >> > >> > >> >> Bernhard >> > >> > >> >> > >> >> > Martin >> >> > >> >> > >> >> > >> >> > >> > >> > ------------------------------------------------------------------ >> > ------------ >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > Foam-extend-developers mailing list >> >> > Foa...@li... >> > <mailto:Foa...@li...> >> >> <mailto:Foa...@li... >> > <mailto:Foa...@li...>> >> >> > >> > https://lists.sourceforge.net/lists/listinfo/foam-extend-develop >> > ers >> >> > >> > >> > >> > ------------------------------------------------------------------ >> > ------------ >> >> _______________________________________________ >> >> Foam-extend-developers mailing list >> >> Foa...@li... >> > <mailto:Foa...@li...> >> >> <mailto:Foa...@li... >> > <mailto:Foa...@li...>> >> > >> > https://lists.sourceforge.net/lists/listinfo/foam-extend-developer >> > s >> > >> > >> > >> > >> >> -- >> >> Martin Beaudoin >> > >> > >> > >> > ---------------------------------------------------------------------- >> > -------- >> > >> > >> > >> >> _______________________________________________ >> >> Foam-extend-developers mailing list >> >> Foa...@li... >> > <mailto:Foa...@li...> >> >> https://lists.sourceforge.net/lists/listinfo/foam-extend-developers >> > >> > >> > >> ------------------------------------------------------------------------------ >> > _______________________________________________ >> > Foam-extend-developers mailing list >> > Foa...@li... >> > <mailto:Foa...@li...> >> > >> https://lists.sourceforge.net/lists/listinfo/foam-extend-developers >> > >> > >> > >> > >> > -- >> > Martin Beaudoin >> > >> > >> > >> > >> > -- >> > Martin Beaudoin >> > >> > >> > >> ------------------------------------------------------------------------------ >> > >> > >> > >> > _______________________________________________ >> > Foam-extend-developers mailing list >> > Foa...@li... >> > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers >> > >> -----BEGIN PGP SIGNATURE----- >> Comment: GPGTools - https://gpgtools.org >> >> iEYEARECAAYFAlZW3R0ACgkQXIMfp1I+9MFEaQCfWD8axrfJs2JL2lhV4o4V0g1y >> cr0AoMvgwY4fOdpwfzadrAjcLnDBJ5jw >> =q9a3 >> -----END PGP SIGNATURE----- >> >> >> ------------------------------------------------------------------------------ >> Go from Idea to Many App Stores Faster with Intel(R) XDK >> Give your users amazing mobile app experiences with Intel(R) XDK. >> Use one codebase in this all-in-one HTML5 development environment. >> Design, debug & build mobile apps & 2D/3D high-impact games for multiple >> OSs. >> http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140 >> _______________________________________________ >> Foam-extend-developers mailing list >> Foa...@li... >> https://lists.sourceforge.net/lists/listinfo/foam-extend-developers >> > > > > -- > Martin Beaudoin > -- Martin Beaudoin |
|
From: Martin B. <bea...@gm...> - 2015-11-26 14:32:51
|
Indeed, a dirt cheap full-fledge Linux machine. Since it appears the processor of the Pi zero is very similar to the Pi 1 processor, I am pretty sure that Foam would work on this device too. I was able to compile and run foam-extend on my little Pi1 device prior to building my little Pi2 cluster. Not a whole lot of RAM (same as the Pi 1), but hey, you got already plenty for what you are paying for. I think reliable configurations are available to access this device though one of its USB port (either serial-over-USB or Ethernet-over-USB access), so we could have a relatively cheap 'Foam on a stick' solution for the workshop. The main US reseller of the Pi Zero is already out of stock for the bare bone device, so I guess people are already shopping for their Xmas stockings :) Martin On Thu, Nov 26, 2015 at 5:21 AM, Bernhard Gschaider <bgs...@ic...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > THAT looks exciting: https://www.raspberrypi.org/blog/raspberry-pi-zero/ > > Bernhard > > Am 29.10.15 um 06:31 schrieb Martin Beaudoin: > > > > On Wed, Oct 28, 2015 at 9:36 PM, Martin Beaudoin > > <bea...@gm... <mailto:bea...@gm...>> wrote: > > > > > > > > On Wed, Oct 28, 2015 at 7:45 PM, Bernhard Gschaider > > <bgs...@ic... <mailto:bgs...@ic...>> wrote: > > > > Am 29.10.15 um 00:12 schrieb Martin Beaudoin: > > > >> > As for using such small systems for the Workshop USB > > stick, if w > > e can > >> > figure out a way to USB tether a RaspBerry Pi2 with a > > normal lap > > top + > >> > some kind of terminal app. so we can simply ssh through > > the USB > > link, > >> > then we could have cheaper solution than the Intel stick. > >> > > >> > Here is a rough estimate of the cost in USD$, based on > > the units > > I have > >> > bought so far: > >> > > >> > * RaspBerry Pi 2 Model B : 35$ > >> > * 32GB Ultra MicroSDHC Class 10 card: 15$ > >> > * A Raspberry Pi2 case : 10$ > >> > * A USB cable for power and tether : 5$ > >> > > >> > For a total of roughly 65 $USD. > >> > > >> > And a 32GB card is slightly roomy. The OS is free, and > > the recip > > e to > >> > deploy foam-extend over this device is known. > >> > > >> > And we are still not talking bulk pricing here. I am > > sure we can > > shave a > >> > few $ if we buy a 100 of those... > >> > > >> > So the only piece of the puzzle remaining is a little > > bit of sof > > tware > >> > for USB tethering.... > >> > > >> > Maybe we can do all this as well with an Intel Compute > > stick. Bo > > th > >> > solutions would be way cool... > > > >> But the ultimate decision is of course with the Workshop > > organizer > > . > >> Because of course the logistics for the production of > > USB-keys is > >> already known > > > >> But lets see if we find something > > > > > >> Some other possible avenues to link a Pi2 with a good old > >> Linux/Mac/Windows laptop: > > > >> * Ethernet to Ethernet using an Ethernet crossover patch cable. > >> Needs an Ethernet port on the laptop, which no longer comes standa > > rd > >> on some laptops (MacBook Air) > >> Probably needs to add some kind of additional network routing to > >> make this work while the laptop is still connected to the OFW wifi > >> hotspot > > > > Something like this > > http://diyhacking.com/connect-raspberry-pi-to-laptop-display/ > > > > What is not funny here is that for every OS setting up the > > network is > > different (plus that some people might not have the privileges > > for this) > > > > > >> Yep, not an attractive solution for a whole group of various and > >> different platforms or OSes. > >> Too much time will be needed to set this up prior to starting the > >> trainings and such... > > > > > >> * Wifi access > >> We can transform the Pi2 as a Wifi Access point so the laptop can > >> establish a WIFI connection directly with the Pi2. > >> We need to add a decent WIFI USB dongle to the Pi2 (+ ~12 USD$) > >> Having a room full of 10s of little WIFI Access points/routers wou > > ld > >> be a very funny and probably inextricable mess > > > > And every RasPi would have to be setup differently so that it can be > > paired (otherwise Joe will connect to Abduhls RasPi) > > > > Note really feasible > > > > > >> Indeed. > > > > > > > >> * Serial over USB > >> The laptop would connect unidirectionally the Pi2 using an emulat > > ed > >> serial/terminal console available over one of the 4 USB ports > >> available on the Pi2 > >> Ohhhhhhh, maybe we have something worth exploring here too..... > >> Kermit anyone? LOL :):) > > > > http://workshop.raspberrypiaustralia.com/usb/ttl/connecting/2014/08/31/0 > > 1-connecting-to-raspberry-pi-via-usb/ > > < > http://workshop.raspberrypiaustralia.com/usb/ttl/connecting/2014/08/31/01-connecting-to-raspberry-pi-via-usb/ > > > > > > Needs additional hardware and the correct cable > > > > > >> And we cannot run paraview over a mere ASCII console.... Not a great > >> all around solution. > > > > > >> * TCP/IP over USB > >> Looks like we need a special kind of cable for this > >> Still investigating.... > > > >> But definitely, the USB port is probably the most universal connector > >> still available on a multitude of hardware platforms. Let's find a way > >> to talk to this little guy... > > > > I can't think of another way than the ones you listed. To be honest: > > none of them convinces me when I think of the support problems > > they're > > going to raise. But I'll keep looking > > > > > >> Yup, we need something easy to setup, and based on some really > >> common laptop applications like Putty or MobaXterm for Windows, or X > >> Windows over ssh for OSX or Linux. The complexity of this setup has > >> to remain on the Pi2 side so we can configure it correctly ourselves > >> prior to distributing these little beast... > > > >> Going back hunting... > > > > > >> Looks like there is no way around it, a USB to USB connection requires a > >> fancy USB Bridge cable with some electronics embedded in the cable. > >> Basically, USB cannot do host to host without this kind of device. See > >> here for the details : http://www.linux-usb.org/usbnet/ > > > >> So it looks to me the best and most flexible option now becomes using > >> the Pi2 Ethernet port + short Ethernet cable + Ethernet to USB adapter. > > > >> I can find on Amazon some USB 2.0 to 10/100 Fast Ethernet LAN Wired > >> Network Adapter for about 20 $USD. > >> A short flat Ethernet cable can be bought for about 1$. > >> Still bearable. > > > >> For laptops having there own embedded Ethernet port, the Ethernet to USB > >> adapter is not necessary, of course, but still remains convenient when > >> going back to the office and having to plug back into the wired > >> corporate network while still keeping connected with the Pi2. For > >> laptops like the MacBook Air lacking an embedded Ethernet port, such > >> Ethernet adapters would be necessary to connect to the Pi2 over > Ethernet. > > > >> So the challenge is now to find a simple Ethernet to Ethernet network > >> setup that will work for Windows, OSX and Linux. > >> Configuring the Pi2 to act as a local DHCP server for this Ethernet link > >> might be a good starting point. > >> I already got a similar setup for my little Pi2 cluster. Let's try to > >> see if I can make this fly... > > > >> Martin > > > >> Martin > > > > > > Bernhard > > > > > > > >> Martin > > > > > > > >> Bernhard > > > > > >> > > >> > Martin > >> > > >> > > >> > > >> > > > > > ------------------------------------------------------------------ > > ------------ > >> > > >> > > >> > > >> > _______________________________________________ > >> > Foam-extend-developers mailing list > >> > Foa...@li... > > <mailto:Foa...@li...> > >> <mailto:Foa...@li... > > <mailto:Foa...@li...>> > >> > > > https://lists.sourceforge.net/lists/listinfo/foam-extend-develop > > ers > >> > > > > > > > ------------------------------------------------------------------ > > ------------ > >> _______________________________________________ > >> Foam-extend-developers mailing list > >> Foa...@li... > > <mailto:Foa...@li...> > >> <mailto:Foa...@li... > > <mailto:Foa...@li...>> > > > > https://lists.sourceforge.net/lists/listinfo/foam-extend-developer > > s > > > > > > > > > >> -- > >> Martin Beaudoin > > > > > > > > ---------------------------------------------------------------------- > > -------- > > > > > > > >> _______________________________________________ > >> Foam-extend-developers mailing list > >> Foa...@li... > > <mailto:Foa...@li...> > >> https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Foam-extend-developers mailing list > > Foa...@li... > > <mailto:Foa...@li...> > > > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > > > > > > > > > > -- > > Martin Beaudoin > > > > > > > > > > -- > > Martin Beaudoin > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > Foam-extend-developers mailing list > > Foa...@li... > > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > > > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - https://gpgtools.org > > iEYEARECAAYFAlZW3R0ACgkQXIMfp1I+9MFEaQCfWD8axrfJs2JL2lhV4o4V0g1y > cr0AoMvgwY4fOdpwfzadrAjcLnDBJ5jw > =q9a3 > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------------ > Go from Idea to Many App Stores Faster with Intel(R) XDK > Give your users amazing mobile app experiences with Intel(R) XDK. > Use one codebase in this all-in-one HTML5 development environment. > Design, debug & build mobile apps & 2D/3D high-impact games for multiple > OSs. > http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140 > _______________________________________________ > Foam-extend-developers mailing list > Foa...@li... > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > -- Martin Beaudoin |
|
From: Bernhard G. <bgs...@ic...> - 2015-11-26 10:21:29
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 THAT looks exciting: https://www.raspberrypi.org/blog/raspberry-pi-zero/ Bernhard Am 29.10.15 um 06:31 schrieb Martin Beaudoin: > > On Wed, Oct 28, 2015 at 9:36 PM, Martin Beaudoin > <bea...@gm... <mailto:bea...@gm...>> wrote: > > > > On Wed, Oct 28, 2015 at 7:45 PM, Bernhard Gschaider > <bgs...@ic... <mailto:bgs...@ic...>> wrote: > > Am 29.10.15 um 00:12 schrieb Martin Beaudoin: > >> > As for using such small systems for the Workshop USB > stick, if w > e can >> > figure out a way to USB tether a RaspBerry Pi2 with a > normal lap > top + >> > some kind of terminal app. so we can simply ssh through > the USB > link, >> > then we could have cheaper solution than the Intel stick. >> > >> > Here is a rough estimate of the cost in USD$, based on > the units > I have >> > bought so far: >> > >> > * RaspBerry Pi 2 Model B : 35$ >> > * 32GB Ultra MicroSDHC Class 10 card: 15$ >> > * A Raspberry Pi2 case : 10$ >> > * A USB cable for power and tether : 5$ >> > >> > For a total of roughly 65 $USD. >> > >> > And a 32GB card is slightly roomy. The OS is free, and > the recip > e to >> > deploy foam-extend over this device is known. >> > >> > And we are still not talking bulk pricing here. I am > sure we can > shave a >> > few $ if we buy a 100 of those... >> > >> > So the only piece of the puzzle remaining is a little > bit of sof > tware >> > for USB tethering.... >> > >> > Maybe we can do all this as well with an Intel Compute > stick. Bo > th >> > solutions would be way cool... > >> But the ultimate decision is of course with the Workshop > organizer > . >> Because of course the logistics for the production of > USB-keys is >> already known > >> But lets see if we find something > > >> Some other possible avenues to link a Pi2 with a good old >> Linux/Mac/Windows laptop: > >> * Ethernet to Ethernet using an Ethernet crossover patch cable. >> Needs an Ethernet port on the laptop, which no longer comes standa > rd >> on some laptops (MacBook Air) >> Probably needs to add some kind of additional network routing to >> make this work while the laptop is still connected to the OFW wifi >> hotspot > > Something like this > http://diyhacking.com/connect-raspberry-pi-to-laptop-display/ > > What is not funny here is that for every OS setting up the > network is > different (plus that some people might not have the privileges > for this) > > >> Yep, not an attractive solution for a whole group of various and >> different platforms or OSes. >> Too much time will be needed to set this up prior to starting the >> trainings and such... > > >> * Wifi access >> We can transform the Pi2 as a Wifi Access point so the laptop can >> establish a WIFI connection directly with the Pi2. >> We need to add a decent WIFI USB dongle to the Pi2 (+ ~12 USD$) >> Having a room full of 10s of little WIFI Access points/routers wou > ld >> be a very funny and probably inextricable mess > > And every RasPi would have to be setup differently so that it can be > paired (otherwise Joe will connect to Abduhls RasPi) > > Note really feasible > > >> Indeed. > > > >> * Serial over USB >> The laptop would connect unidirectionally the Pi2 using an emulat > ed >> serial/terminal console available over one of the 4 USB ports >> available on the Pi2 >> Ohhhhhhh, maybe we have something worth exploring here too..... >> Kermit anyone? LOL :):) > > http://workshop.raspberrypiaustralia.com/usb/ttl/connecting/2014/08/31/0 > 1-connecting-to-raspberry-pi-via-usb/ > <http://workshop.raspberrypiaustralia.com/usb/ttl/connecting/2014/08/31/01-connecting-to-raspberry-pi-via-usb/> > > Needs additional hardware and the correct cable > > >> And we cannot run paraview over a mere ASCII console.... Not a great >> all around solution. > > >> * TCP/IP over USB >> Looks like we need a special kind of cable for this >> Still investigating.... > >> But definitely, the USB port is probably the most universal connector >> still available on a multitude of hardware platforms. Let's find a way >> to talk to this little guy... > > I can't think of another way than the ones you listed. To be honest: > none of them convinces me when I think of the support problems > they're > going to raise. But I'll keep looking > > >> Yup, we need something easy to setup, and based on some really >> common laptop applications like Putty or MobaXterm for Windows, or X >> Windows over ssh for OSX or Linux. The complexity of this setup has >> to remain on the Pi2 side so we can configure it correctly ourselves >> prior to distributing these little beast... > >> Going back hunting... > > >> Looks like there is no way around it, a USB to USB connection requires a >> fancy USB Bridge cable with some electronics embedded in the cable. >> Basically, USB cannot do host to host without this kind of device. See >> here for the details : http://www.linux-usb.org/usbnet/ > >> So it looks to me the best and most flexible option now becomes using >> the Pi2 Ethernet port + short Ethernet cable + Ethernet to USB adapter. > >> I can find on Amazon some USB 2.0 to 10/100 Fast Ethernet LAN Wired >> Network Adapter for about 20 $USD. >> A short flat Ethernet cable can be bought for about 1$. >> Still bearable. > >> For laptops having there own embedded Ethernet port, the Ethernet to USB >> adapter is not necessary, of course, but still remains convenient when >> going back to the office and having to plug back into the wired >> corporate network while still keeping connected with the Pi2. For >> laptops like the MacBook Air lacking an embedded Ethernet port, such >> Ethernet adapters would be necessary to connect to the Pi2 over Ethernet. > >> So the challenge is now to find a simple Ethernet to Ethernet network >> setup that will work for Windows, OSX and Linux. >> Configuring the Pi2 to act as a local DHCP server for this Ethernet link >> might be a good starting point. >> I already got a similar setup for my little Pi2 cluster. Let's try to >> see if I can make this fly... > >> Martin > >> Martin > > > Bernhard > > > >> Martin > > > >> Bernhard > > >> > >> > Martin >> > >> > >> > >> > > > ------------------------------------------------------------------ > ------------ >> > >> > >> > >> > _______________________________________________ >> > Foam-extend-developers mailing list >> > Foa...@li... > <mailto:Foa...@li...> >> <mailto:Foa...@li... > <mailto:Foa...@li...>> >> > > https://lists.sourceforge.net/lists/listinfo/foam-extend-develop > ers >> > > > > ------------------------------------------------------------------ > ------------ >> _______________________________________________ >> Foam-extend-developers mailing list >> Foa...@li... > <mailto:Foa...@li...> >> <mailto:Foa...@li... > <mailto:Foa...@li...>> > > https://lists.sourceforge.net/lists/listinfo/foam-extend-developer > s > > > > >> -- >> Martin Beaudoin > > > > ---------------------------------------------------------------------- > -------- > > > >> _______________________________________________ >> Foam-extend-developers mailing list >> Foa...@li... > <mailto:Foa...@li...> >> https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > > > ------------------------------------------------------------------------------ > _______________________________________________ > Foam-extend-developers mailing list > Foa...@li... > <mailto:Foa...@li...> > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > > > > > -- > Martin Beaudoin > > > > > -- > Martin Beaudoin > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Foam-extend-developers mailing list > Foa...@li... > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAlZW3R0ACgkQXIMfp1I+9MFEaQCfWD8axrfJs2JL2lhV4o4V0g1y cr0AoMvgwY4fOdpwfzadrAjcLnDBJ5jw =q9a3 -----END PGP SIGNATURE----- |
|
From: Martin B. <bea...@gm...> - 2015-11-25 15:26:18
|
On Wed, Nov 25, 2015 at 6:26 AM, Hrvoje Jasak <hrv...@fs...> wrote: > Why don't we force gzip instead - in my experience, this is smaller than > binary. > Good point. I guess we could offer a few compile-time options to tackle this issue with more flexibility. Indeed, we often get smaller file size with gzip, but I would argue that this is mainly because we are compressing ASCII-converted floating-point values with a small number of significant digits (for example, the still very common: writePrecision 6). My main issues with the ASCII writeFormat is of course the waste of storage space, but also self-imposed loss of numerical resolution when storing our solutions on disk. On one hand we are computing (quite often for weeks at a time on large super-computers ) numerically sensitive algorithms using double precision floating point values, but we only store 6 of 7 significant digits for our intermediary or final results. This kind of resolution is fine for storing meshes coordinates or for visualization purposes with paraView, but for restarting a simulation from a set of solutions stored on disk, I am not so sure about the impact of this loss of resolution on the first few iterations. Would be nice to do an numerical analysis here on a broad set of solvers. And doing post-processing of self-imposed low-resolution numerical values while knowing that we threw away to the full double-precision information in the first place has always troubled me a bit. As for the gzip option, if you offer me the choice between two human-nonreadable file formats, binary vs ASCII gzipped, I will prefer uncompressed binary, which offers me full numerical resolution, and without wasting any CPU time doing compression. I think the ASCII writeFormat is very useful for learning or discovering this simulation platform, and we should keep it. But when moving to the realm of simulation of millions-cells problems, users usually do not revisit this option, and data centers all over the world hosting Foam CFD computations are suffering from this kind of user oversight, or need to do a lot of users hand-holding. I am basically looking for a well-balanced option here, while working on a possibly better solution HPC-wise... More about this later. Martin > > I'd like to hear other opinions, but I am open to any good ideas > > HJ > > > On 25 Nov 2015, at 03:16, Martin Beaudoin <bea...@gm...> > wrote: > > > > Hello, > > > > I am seriously considering disabling the ASCII writeFormat when meshes > are larger than a predefined cells number. > > > > The idea is to still offer the ASCII writeFormat for small cases (which > is useful for testing or training), but to mark it as unavailable when > running simulations with serious size meshes, let's say larger than 10k > cells. > > > > For larger meshes, the user would be forced to use the binary > writeFormat. > > > > The specific mesh size would be defined at compile time, so site admins > would be able to adjust this number if need be, but this number would not > be overridable at runtime by users. > > > > The amount of storage space wasted on Foam/OpenFOAM meshes and solutions > ASCII files is just too important. > > > > Thank you for your comments on this "radical" idea. > > > > Martin > > > > > ------------------------------------------------------------------------------ > > Go from Idea to Many App Stores Faster with Intel(R) XDK > > Give your users amazing mobile app experiences with Intel(R) XDK. > > Use one codebase in this all-in-one HTML5 development environment. > > Design, debug & build mobile apps & 2D/3D high-impact games for multiple > OSs. > > http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140 > > _______________________________________________ > > Foam-extend-developers mailing list > > Foa...@li... > > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > > > ------------------------------------------------------------------------------ > Go from Idea to Many App Stores Faster with Intel(R) XDK > Give your users amazing mobile app experiences with Intel(R) XDK. > Use one codebase in this all-in-one HTML5 development environment. > Design, debug & build mobile apps & 2D/3D high-impact games for multiple > OSs. > http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140 > _______________________________________________ > Foam-extend-developers mailing list > Foa...@li... > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > -- Martin Beaudoin |
|
From: Hrvoje J. <hrv...@fs...> - 2015-11-25 11:26:39
|
Why don't we force gzip instead - in my experience, this is smaller than binary. I'd like to hear other opinions, but I am open to any good ideas HJ > On 25 Nov 2015, at 03:16, Martin Beaudoin <bea...@gm...> wrote: > > Hello, > > I am seriously considering disabling the ASCII writeFormat when meshes are larger than a predefined cells number. > > The idea is to still offer the ASCII writeFormat for small cases (which is useful for testing or training), but to mark it as unavailable when running simulations with serious size meshes, let's say larger than 10k cells. > > For larger meshes, the user would be forced to use the binary writeFormat. > > The specific mesh size would be defined at compile time, so site admins would be able to adjust this number if need be, but this number would not be overridable at runtime by users. > > The amount of storage space wasted on Foam/OpenFOAM meshes and solutions ASCII files is just too important. > > Thank you for your comments on this "radical" idea. > > Martin > > ------------------------------------------------------------------------------ > Go from Idea to Many App Stores Faster with Intel(R) XDK > Give your users amazing mobile app experiences with Intel(R) XDK. > Use one codebase in this all-in-one HTML5 development environment. > Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. > http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140 > _______________________________________________ > Foam-extend-developers mailing list > Foa...@li... > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers |
|
From: Martin B. <bea...@gm...> - 2015-11-25 03:16:52
|
Hello, I am seriously considering disabling the ASCII writeFormat when meshes are larger than a predefined cells number. The idea is to still offer the ASCII writeFormat for small cases (which is useful for testing or training), but to mark it as unavailable when running simulations with serious size meshes, let's say larger than 10k cells. For larger meshes, the user would be forced to use the binary writeFormat. The specific mesh size would be defined at compile time, so site admins would be able to adjust this number if need be, but this number would not be overridable at runtime by users. The amount of storage space wasted on Foam/OpenFOAM meshes and solutions ASCII files is just too important. Thank you for your comments on this "radical" idea. Martin |
|
From: Martin B. <bea...@gm...> - 2015-11-04 17:42:11
|
On Tue, Nov 3, 2015 at 12:11 PM, Bernhard Gschaider <bgs...@ic...> wrote: > Am 02.11.15 um 23:59 schrieb Martin Beaudoin: > > > > > > On Mon, Nov 2, 2015 at 5:39 PM, Bernhard Gschaider <bgs...@ic... > > <mailto:bgs...@ic...>> wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hi! > > > > Am 02.11.15 um 23:20 schrieb Martin Beaudoin: > > > Yep, this is an incoherence that quite often did bite me for the > compiler. > > > So I totally agree with your analysis and your proposition for the > > > install path for gcc. > > > > Another thing that I just saw: in the spec-files gcc is "only" > > configured for the languages c and c++. Shouldn't fortran be added as > > well. Some packages (mesquite, Zoltan, libccmio) have Fortran sources > > and having a "fitting" gfortran might help avoid problems. > > > > > > Sure. Having a more complete set of Gnu compilers can't be bad if one > > want to explore additional Fortran libraries with Foam. > > Just takes longer to compile, but this is a one time cost. > One of the spec-files already uses WM_FC to set the standard F###-compiler > (Like WM_CC). To be consistent it should be set in the .sh files of the > RPMs and we should use it generally > > Ok. > > > > > > > However, I am not sure that we should do the same for the rest of > the > > > AllMake.stage1 packages. > > > > > > For example, If we ever build a test loop for the compilation and > test > > > of the ThirdParty packages (which I think we really need), it > could be > > > nice to detect that a given version of flex does not run correctly > when > > > compiled with a given version of gcc, or that we have problems with > > > cmake in SP. > > > > OK. Although I'm not sure whether Foam actually links to the > > flex-library or just code generated by flex is compiled (I only see > > problems in the first case). cmake/SP is not a good example I'd say. > > Basically SP (correct me if I'm wrong) "only" modifies the > definition of > > scalar. The cmake.spec that I looked at doesn't care whether SP/DP is > > set. It might be affected by the compiler that is used > > > > > > Yep, not a great example... I still think discriminating a ThirdParty > > package by the compiler that was used to compile it might be useful, so > > I feel hesitant to make too much changes here. > Understandable. As I'm not willing to test it I won't propose anything > that breaks it > > > > > > > > > So I would tend to keep the actual naming scheme for the other > packages > > > from stage1. > > > But I am quite open discuss this some more. > > > > To be honest: gcc is the most important I think. Its compilation > time is > > more than all the other packages in that stage combined. So following > > the 90/10 rule I'd only change that and the rest is insignificant > > > > Yep... > > > > So do you want to propose the changes yourself, or do you want me to > > have a look at this? > Could you please? > Ok. I will have a look as soon as possible. Martin > > Bernhard > > > > > > Martin > > > > > > Bernhard > > > > > > > > Martin > > > > > > > > > On Mon, Nov 2, 2015 at 4:53 PM, Bernhard Gschaider < > bgs...@ic... <mailto:bgs...@ic...> > > > <mailto:bgs...@ic... <mailto:bgs...@ic...>>> wrote: > > > > > > Hi Martin! > > > > > > (I use darwinIntel64 in this mail but it might be Linux64 or SunOS > > > as well) > > > > > > While working on the initalization scripts I stumbled on this: in > > order > > > to test the compiler being used from a ThirdParty-RPM I built a > > gcc 4.8 > > > rpm with the "standard" settings. Therefore the rpm installs > itself to > > > ThirdParty/packages/gcc-4.8.4/platforms/darwinIntel64GccDPOpt/ > when I > > > initialize with WM_COMPILER=Gcc48 then the way it is sourced in > > > etc/settings it looks for the compiler in > > > ThirdParty/packages/gcc-4.8.4/platforms/darwinIntel64Gcc48DPOpt/ > > > > > > This is not a problem that a symbolic link can't fix. But it > > occurred to > > > me that having the compiler version as part of the package > > specification > > > is a bit of an overkill. After all the compiler "only" bootstraps > the > > > rest of the packages and compiles Foam. Even the distinction DP/SP > > > Opt/Debug is IMHO irrelevant. So wouldn't it be sufficient to > > build the > > > compiler packages so that they install to > > > ThirdParty/packages/gcc-4.8.4/platforms/darwinIntel64 (and the > release > > > version of the RPMs is also "only" darwinIntel64) > > > > > > In fact: I think this naming is applicable for all packages built > > in the > > > AllMake.stage1-script (all others are linked against Foam-binaries > > so I > > > think it is a great idea to have separate packages to avoid > problems > > > with different ABI-versions) > > > > > > Bernhard > > > > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > > > Foam-extend-developers mailing list > > > Foa...@li... > > <mailto:Foa...@li...> > > > <mailto:Foa...@li... > > <mailto:Foa...@li...>> > > > > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > > > > > > > > > > > > > > > -- > > > Martin Beaudoin > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > _______________________________________________ > > > Foam-extend-developers mailing list > > > Foa...@li... > > <mailto:Foa...@li...> > > > > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > > > > > -----BEGIN PGP SIGNATURE----- > > Comment: GPGTools - https://gpgtools.org > > > > iEYEARECAAYFAlY35g8ACgkQXIMfp1I+9MHeiQCgmSiGPjz0dLmkd7+A7omt84VM > > mF8AnjnDd3t2xGp4sqKfy5YaI2iBKKw6 > > =9/EK > > -----END PGP SIGNATURE----- > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Foam-extend-developers mailing list > > Foa...@li... > > <mailto:Foa...@li...> > > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > > > > > > > > > > -- > > Martin Beaudoin > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > Foam-extend-developers mailing list > > Foa...@li... > > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Foam-extend-developers mailing list > Foa...@li... > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > -- Martin Beaudoin |
|
From: Bernhard G. <bgs...@ic...> - 2015-11-03 17:11:59
|
Am 02.11.15 um 23:59 schrieb Martin Beaudoin: > > > On Mon, Nov 2, 2015 at 5:39 PM, Bernhard Gschaider <bgs...@ic... > <mailto:bgs...@ic...>> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi! > > Am 02.11.15 um 23:20 schrieb Martin Beaudoin: > > Yep, this is an incoherence that quite often did bite me for the compiler. > > So I totally agree with your analysis and your proposition for the > > install path for gcc. > > Another thing that I just saw: in the spec-files gcc is "only" > configured for the languages c and c++. Shouldn't fortran be added as > well. Some packages (mesquite, Zoltan, libccmio) have Fortran sources > and having a "fitting" gfortran might help avoid problems. > > > Sure. Having a more complete set of Gnu compilers can't be bad if one > want to explore additional Fortran libraries with Foam. > Just takes longer to compile, but this is a one time cost. One of the spec-files already uses WM_FC to set the standard F###-compiler (Like WM_CC). To be consistent it should be set in the .sh files of the RPMs and we should use it generally > > > > However, I am not sure that we should do the same for the rest of the > > AllMake.stage1 packages. > > > > For example, If we ever build a test loop for the compilation and test > > of the ThirdParty packages (which I think we really need), it could be > > nice to detect that a given version of flex does not run correctly when > > compiled with a given version of gcc, or that we have problems with > > cmake in SP. > > OK. Although I'm not sure whether Foam actually links to the > flex-library or just code generated by flex is compiled (I only see > problems in the first case). cmake/SP is not a good example I'd say. > Basically SP (correct me if I'm wrong) "only" modifies the definition of > scalar. The cmake.spec that I looked at doesn't care whether SP/DP is > set. It might be affected by the compiler that is used > > > Yep, not a great example... I still think discriminating a ThirdParty > package by the compiler that was used to compile it might be useful, so > I feel hesitant to make too much changes here. Understandable. As I'm not willing to test it I won't propose anything that breaks it > > > > So I would tend to keep the actual naming scheme for the other packages > > from stage1. > > But I am quite open discuss this some more. > > To be honest: gcc is the most important I think. Its compilation time is > more than all the other packages in that stage combined. So following > the 90/10 rule I'd only change that and the rest is insignificant > > Yep... > > So do you want to propose the changes yourself, or do you want me to > have a look at this? Could you please? Bernhard > > Martin > > > Bernhard > > > > > Martin > > > > > > On Mon, Nov 2, 2015 at 4:53 PM, Bernhard Gschaider <bgs...@ic... <mailto:bgs...@ic...> > > <mailto:bgs...@ic... <mailto:bgs...@ic...>>> wrote: > > > > Hi Martin! > > > > (I use darwinIntel64 in this mail but it might be Linux64 or SunOS > > as well) > > > > While working on the initalization scripts I stumbled on this: in > order > > to test the compiler being used from a ThirdParty-RPM I built a > gcc 4.8 > > rpm with the "standard" settings. Therefore the rpm installs itself to > > ThirdParty/packages/gcc-4.8.4/platforms/darwinIntel64GccDPOpt/ when I > > initialize with WM_COMPILER=Gcc48 then the way it is sourced in > > etc/settings it looks for the compiler in > > ThirdParty/packages/gcc-4.8.4/platforms/darwinIntel64Gcc48DPOpt/ > > > > This is not a problem that a symbolic link can't fix. But it > occurred to > > me that having the compiler version as part of the package > specification > > is a bit of an overkill. After all the compiler "only" bootstraps the > > rest of the packages and compiles Foam. Even the distinction DP/SP > > Opt/Debug is IMHO irrelevant. So wouldn't it be sufficient to > build the > > compiler packages so that they install to > > ThirdParty/packages/gcc-4.8.4/platforms/darwinIntel64 (and the release > > version of the RPMs is also "only" darwinIntel64) > > > > In fact: I think this naming is applicable for all packages built > in the > > AllMake.stage1-script (all others are linked against Foam-binaries > so I > > think it is a great idea to have separate packages to avoid problems > > with different ABI-versions) > > > > Bernhard > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Foam-extend-developers mailing list > > Foa...@li... > <mailto:Foa...@li...> > > <mailto:Foa...@li... > <mailto:Foa...@li...>> > > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > > > > > > > > > > -- > > Martin Beaudoin > > > > > > ------------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > Foam-extend-developers mailing list > > Foa...@li... > <mailto:Foa...@li...> > > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > > > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - https://gpgtools.org > > iEYEARECAAYFAlY35g8ACgkQXIMfp1I+9MHeiQCgmSiGPjz0dLmkd7+A7omt84VM > mF8AnjnDd3t2xGp4sqKfy5YaI2iBKKw6 > =9/EK > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > _______________________________________________ > Foam-extend-developers mailing list > Foa...@li... > <mailto:Foa...@li...> > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > > > > > -- > Martin Beaudoin > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Foam-extend-developers mailing list > Foa...@li... > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > |
|
From: Martin B. <bea...@gm...> - 2015-11-02 23:00:26
|
On Mon, Nov 2, 2015 at 5:39 PM, Bernhard Gschaider <bgs...@ic...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi! > > Am 02.11.15 um 23:20 schrieb Martin Beaudoin: > > Yep, this is an incoherence that quite often did bite me for the > compiler. > > So I totally agree with your analysis and your proposition for the > > install path for gcc. > > Another thing that I just saw: in the spec-files gcc is "only" > configured for the languages c and c++. Shouldn't fortran be added as > well. Some packages (mesquite, Zoltan, libccmio) have Fortran sources > and having a "fitting" gfortran might help avoid problems. > Sure. Having a more complete set of Gnu compilers can't be bad if one want to explore additional Fortran libraries with Foam. Just takes longer to compile, but this is a one time cost. > > However, I am not sure that we should do the same for the rest of the > > AllMake.stage1 packages. > > > > For example, If we ever build a test loop for the compilation and test > > of the ThirdParty packages (which I think we really need), it could be > > nice to detect that a given version of flex does not run correctly when > > compiled with a given version of gcc, or that we have problems with > > cmake in SP. > > OK. Although I'm not sure whether Foam actually links to the > flex-library or just code generated by flex is compiled (I only see > problems in the first case). cmake/SP is not a good example I'd say. > Basically SP (correct me if I'm wrong) "only" modifies the definition of > scalar. The cmake.spec that I looked at doesn't care whether SP/DP is > set. It might be affected by the compiler that is used > > Yep, not a great example... I still think discriminating a ThirdParty package by the compiler that was used to compile it might be useful, so I feel hesitant to make too much changes here. > > So I would tend to keep the actual naming scheme for the other packages > > from stage1. > > But I am quite open discuss this some more. > > To be honest: gcc is the most important I think. Its compilation time is > more than all the other packages in that stage combined. So following > the 90/10 rule I'd only change that and the rest is insignificant > > Yep... So do you want to propose the changes yourself, or do you want me to have a look at this? Martin > Bernhard > > > > > Martin > > > > > > On Mon, Nov 2, 2015 at 4:53 PM, Bernhard Gschaider <bgs...@ic... > > <mailto:bgs...@ic...>> wrote: > > > > Hi Martin! > > > > (I use darwinIntel64 in this mail but it might be Linux64 or SunOS > > as well) > > > > While working on the initalization scripts I stumbled on this: in order > > to test the compiler being used from a ThirdParty-RPM I built a gcc 4.8 > > rpm with the "standard" settings. Therefore the rpm installs itself to > > ThirdParty/packages/gcc-4.8.4/platforms/darwinIntel64GccDPOpt/ when I > > initialize with WM_COMPILER=Gcc48 then the way it is sourced in > > etc/settings it looks for the compiler in > > ThirdParty/packages/gcc-4.8.4/platforms/darwinIntel64Gcc48DPOpt/ > > > > This is not a problem that a symbolic link can't fix. But it occurred to > > me that having the compiler version as part of the package specification > > is a bit of an overkill. After all the compiler "only" bootstraps the > > rest of the packages and compiles Foam. Even the distinction DP/SP > > Opt/Debug is IMHO irrelevant. So wouldn't it be sufficient to build the > > compiler packages so that they install to > > ThirdParty/packages/gcc-4.8.4/platforms/darwinIntel64 (and the release > > version of the RPMs is also "only" darwinIntel64) > > > > In fact: I think this naming is applicable for all packages built in the > > AllMake.stage1-script (all others are linked against Foam-binaries so I > > think it is a great idea to have separate packages to avoid problems > > with different ABI-versions) > > > > Bernhard > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Foam-extend-developers mailing list > > Foa...@li... > > <mailto:Foa...@li...> > > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > > > > > > > > > > -- > > Martin Beaudoin > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > Foam-extend-developers mailing list > > Foa...@li... > > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > > > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - https://gpgtools.org > > iEYEARECAAYFAlY35g8ACgkQXIMfp1I+9MHeiQCgmSiGPjz0dLmkd7+A7omt84VM > mF8AnjnDd3t2xGp4sqKfy5YaI2iBKKw6 > =9/EK > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------------ > _______________________________________________ > Foam-extend-developers mailing list > Foa...@li... > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > -- Martin Beaudoin |
|
From: Bernhard G. <bgs...@ic...> - 2015-11-02 22:39:26
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Am 02.11.15 um 23:20 schrieb Martin Beaudoin: > Yep, this is an incoherence that quite often did bite me for the compiler. > So I totally agree with your analysis and your proposition for the > install path for gcc. Another thing that I just saw: in the spec-files gcc is "only" configured for the languages c and c++. Shouldn't fortran be added as well. Some packages (mesquite, Zoltan, libccmio) have Fortran sources and having a "fitting" gfortran might help avoid problems. > However, I am not sure that we should do the same for the rest of the > AllMake.stage1 packages. > > For example, If we ever build a test loop for the compilation and test > of the ThirdParty packages (which I think we really need), it could be > nice to detect that a given version of flex does not run correctly when > compiled with a given version of gcc, or that we have problems with > cmake in SP. OK. Although I'm not sure whether Foam actually links to the flex-library or just code generated by flex is compiled (I only see problems in the first case). cmake/SP is not a good example I'd say. Basically SP (correct me if I'm wrong) "only" modifies the definition of scalar. The cmake.spec that I looked at doesn't care whether SP/DP is set. It might be affected by the compiler that is used > So I would tend to keep the actual naming scheme for the other packages > from stage1. > But I am quite open discuss this some more. To be honest: gcc is the most important I think. Its compilation time is more than all the other packages in that stage combined. So following the 90/10 rule I'd only change that and the rest is insignificant Bernhard > > Martin > > > On Mon, Nov 2, 2015 at 4:53 PM, Bernhard Gschaider <bgs...@ic... > <mailto:bgs...@ic...>> wrote: > > Hi Martin! > > (I use darwinIntel64 in this mail but it might be Linux64 or SunOS > as well) > > While working on the initalization scripts I stumbled on this: in order > to test the compiler being used from a ThirdParty-RPM I built a gcc 4.8 > rpm with the "standard" settings. Therefore the rpm installs itself to > ThirdParty/packages/gcc-4.8.4/platforms/darwinIntel64GccDPOpt/ when I > initialize with WM_COMPILER=Gcc48 then the way it is sourced in > etc/settings it looks for the compiler in > ThirdParty/packages/gcc-4.8.4/platforms/darwinIntel64Gcc48DPOpt/ > > This is not a problem that a symbolic link can't fix. But it occurred to > me that having the compiler version as part of the package specification > is a bit of an overkill. After all the compiler "only" bootstraps the > rest of the packages and compiles Foam. Even the distinction DP/SP > Opt/Debug is IMHO irrelevant. So wouldn't it be sufficient to build the > compiler packages so that they install to > ThirdParty/packages/gcc-4.8.4/platforms/darwinIntel64 (and the release > version of the RPMs is also "only" darwinIntel64) > > In fact: I think this naming is applicable for all packages built in the > AllMake.stage1-script (all others are linked against Foam-binaries so I > think it is a great idea to have separate packages to avoid problems > with different ABI-versions) > > Bernhard > > ------------------------------------------------------------------------------ > _______________________________________________ > Foam-extend-developers mailing list > Foa...@li... > <mailto:Foa...@li...> > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > > > > > -- > Martin Beaudoin > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Foam-extend-developers mailing list > Foa...@li... > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAlY35g8ACgkQXIMfp1I+9MHeiQCgmSiGPjz0dLmkd7+A7omt84VM mF8AnjnDd3t2xGp4sqKfy5YaI2iBKKw6 =9/EK -----END PGP SIGNATURE----- |
|
From: Martin B. <bea...@gm...> - 2015-11-02 22:21:25
|
Yep, this is an incoherence that quite often did bite me for the compiler. So I totally agree with your analysis and your proposition for the install path for gcc. However, I am not sure that we should do the same for the rest of the AllMake.stage1 packages. For example, If we ever build a test loop for the compilation and test of the ThirdParty packages (which I think we really need), it could be nice to detect that a given version of flex does not run correctly when compiled with a given version of gcc, or that we have problems with cmake in SP. So I would tend to keep the actual naming scheme for the other packages from stage1. But I am quite open discuss this some more. Martin On Mon, Nov 2, 2015 at 4:53 PM, Bernhard Gschaider <bgs...@ic...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Martin! > > (I use darwinIntel64 in this mail but it might be Linux64 or SunOS as well) > > While working on the initalization scripts I stumbled on this: in order > to test the compiler being used from a ThirdParty-RPM I built a gcc 4.8 > rpm with the "standard" settings. Therefore the rpm installs itself to > ThirdParty/packages/gcc-4.8.4/platforms/darwinIntel64GccDPOpt/ when I > initialize with WM_COMPILER=Gcc48 then the way it is sourced in > etc/settings it looks for the compiler in > ThirdParty/packages/gcc-4.8.4/platforms/darwinIntel64Gcc48DPOpt/ > > This is not a problem that a symbolic link can't fix. But it occurred to > me that having the compiler version as part of the package specification > is a bit of an overkill. After all the compiler "only" bootstraps the > rest of the packages and compiles Foam. Even the distinction DP/SP > Opt/Debug is IMHO irrelevant. So wouldn't it be sufficient to build the > compiler packages so that they install to > ThirdParty/packages/gcc-4.8.4/platforms/darwinIntel64 (and the release > version of the RPMs is also "only" darwinIntel64) > > In fact: I think this naming is applicable for all packages built in the > AllMake.stage1-script (all others are linked against Foam-binaries so I > think it is a great idea to have separate packages to avoid problems > with different ABI-versions) > > Bernhard > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - https://gpgtools.org > > iEYEARECAAYFAlY322wACgkQXIMfp1I+9MG+AQCeNteit02LPMM25CNpSD7n6KdS > x/MAn1mddotaO/oJu+LULfPHKWSBuUI9 > =64hH > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------------ > _______________________________________________ > Foam-extend-developers mailing list > Foa...@li... > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > -- Martin Beaudoin |
|
From: Bernhard G. <bgs...@ic...> - 2015-11-02 21:54:01
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Martin! (I use darwinIntel64 in this mail but it might be Linux64 or SunOS as well) While working on the initalization scripts I stumbled on this: in order to test the compiler being used from a ThirdParty-RPM I built a gcc 4.8 rpm with the "standard" settings. Therefore the rpm installs itself to ThirdParty/packages/gcc-4.8.4/platforms/darwinIntel64GccDPOpt/ when I initialize with WM_COMPILER=Gcc48 then the way it is sourced in etc/settings it looks for the compiler in ThirdParty/packages/gcc-4.8.4/platforms/darwinIntel64Gcc48DPOpt/ This is not a problem that a symbolic link can't fix. But it occurred to me that having the compiler version as part of the package specification is a bit of an overkill. After all the compiler "only" bootstraps the rest of the packages and compiles Foam. Even the distinction DP/SP Opt/Debug is IMHO irrelevant. So wouldn't it be sufficient to build the compiler packages so that they install to ThirdParty/packages/gcc-4.8.4/platforms/darwinIntel64 (and the release version of the RPMs is also "only" darwinIntel64) In fact: I think this naming is applicable for all packages built in the AllMake.stage1-script (all others are linked against Foam-binaries so I think it is a great idea to have separate packages to avoid problems with different ABI-versions) Bernhard -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAlY322wACgkQXIMfp1I+9MG+AQCeNteit02LPMM25CNpSD7n6KdS x/MAn1mddotaO/oJu+LULfPHKWSBuUI9 =64hH -----END PGP SIGNATURE----- |
|
From: Martin B. <bea...@gm...> - 2015-10-29 13:19:45
|
On Thu, Oct 29, 2015 at 1:31 AM, Martin Beaudoin <bea...@gm...> wrote: > > On Wed, Oct 28, 2015 at 9:36 PM, Martin Beaudoin < > bea...@gm...> wrote: > >> >> >> On Wed, Oct 28, 2015 at 7:45 PM, Bernhard Gschaider <bgs...@ic...> >> wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Am 29.10.15 um 00:12 schrieb Martin Beaudoin: >>> >>> > > As for using such small systems for the Workshop USB stick, if w >>> e can >>> > > figure out a way to USB tether a RaspBerry Pi2 with a normal lap >>> top + >>> > > some kind of terminal app. so we can simply ssh through the USB >>> link, >>> > > then we could have cheaper solution than the Intel stick. >>> > > >>> > > Here is a rough estimate of the cost in USD$, based on the units >>> I have >>> > > bought so far: >>> > > >>> > > * RaspBerry Pi 2 Model B : 35$ >>> > > * 32GB Ultra MicroSDHC Class 10 card: 15$ >>> > > * A Raspberry Pi2 case : 10$ >>> > > * A USB cable for power and tether : 5$ >>> > > >>> > > For a total of roughly 65 $USD. >>> > > >>> > > And a 32GB card is slightly roomy. The OS is free, and the recip >>> e to >>> > > deploy foam-extend over this device is known. >>> > > >>> > > And we are still not talking bulk pricing here. I am sure we can >>> shave a >>> > > few $ if we buy a 100 of those... >>> > > >>> > > So the only piece of the puzzle remaining is a little bit of sof >>> tware >>> > > for USB tethering.... >>> > > >>> > > Maybe we can do all this as well with an Intel Compute stick. Bo >>> th >>> > > solutions would be way cool... >>> > >>> > But the ultimate decision is of course with the Workshop organizer >>> . >>> > Because of course the logistics for the production of USB-keys is >>> > already known >>> > >>> > But lets see if we find something >>> > >>> > >>> > Some other possible avenues to link a Pi2 with a good old >>> > Linux/Mac/Windows laptop: >>> > >>> > * Ethernet to Ethernet using an Ethernet crossover patch cable. >>> > Needs an Ethernet port on the laptop, which no longer comes standa >>> rd >>> > on some laptops (MacBook Air) >>> > Probably needs to add some kind of additional network routing to >>> > make this work while the laptop is still connected to the OFW wifi >>> > hotspot >>> >>> Something like this >>> http://diyhacking.com/connect-raspberry-pi-to-laptop-display/ >>> >>> What is not funny here is that for every OS setting up the network is >>> different (plus that some people might not have the privileges for this) >>> >> >> Yep, not an attractive solution for a whole group of various and >> different platforms or OSes. >> Too much time will be needed to set this up prior to starting the >> trainings and such... >> >>> >>> > * Wifi access >>> > We can transform the Pi2 as a Wifi Access point so the laptop can >>> > establish a WIFI connection directly with the Pi2. >>> > We need to add a decent WIFI USB dongle to the Pi2 (+ ~12 USD$) >>> > Having a room full of 10s of little WIFI Access points/routers wou >>> ld >>> > be a very funny and probably inextricable mess >>> >>> And every RasPi would have to be setup differently so that it can be >>> paired (otherwise Joe will connect to Abduhls RasPi) >>> >>> Note really feasible >>> >> >> Indeed. >> >> >>> >>> > * Serial over USB >>> > The laptop would connect unidirectionally the Pi2 using an emulat >>> ed >>> > serial/terminal console available over one of the 4 USB ports >>> > available on the Pi2 >>> > Ohhhhhhh, maybe we have something worth exploring here too..... >>> > Kermit anyone? LOL :):) >>> >>> http://workshop.raspberrypiaustralia.com/usb/ttl/connecting/2014/08/31/0 >>> 1-connecting-to-raspberry-pi-via-usb/ >>> <http://workshop.raspberrypiaustralia.com/usb/ttl/connecting/2014/08/31/01-connecting-to-raspberry-pi-via-usb/> >>> >>> Needs additional hardware and the correct cable >>> >>> >> And we cannot run paraview over a mere ASCII console.... Not a great all >> around solution. >> >> >>> > * TCP/IP over USB >>> > Looks like we need a special kind of cable for this >>> > Still investigating.... >>> > >>> > But definitely, the USB port is probably the most universal connector >>> > still available on a multitude of hardware platforms. Let's find a way >>> > to talk to this little guy... >>> >>> I can't think of another way than the ones you listed. To be honest: >>> none of them convinces me when I think of the support problems they're >>> going to raise. But I'll keep looking >>> >>> >> Yup, we need something easy to setup, and based on some really common >> laptop applications like Putty or MobaXterm for Windows, or X Windows over >> ssh for OSX or Linux. The complexity of this setup has to remain on the Pi2 >> side so we can configure it correctly ourselves prior to distributing these >> little beast... >> >> Going back hunting... >> >> > Looks like there is no way around it, a USB to USB connection requires a > fancy USB Bridge cable with some electronics embedded in the cable. > Basically, USB cannot do host to host without this kind of device. See here > for the details : http://www.linux-usb.org/usbnet/ > > So it looks to me the best and most flexible option now becomes using the > Pi2 Ethernet port + short Ethernet cable + Ethernet to USB adapter. > > I can find on Amazon some USB 2.0 to 10/100 Fast Ethernet LAN Wired > Network Adapter for about 20 $USD. > A short flat Ethernet cable can be bought for about 1$. > Still bearable. > > For laptops having there own embedded Ethernet port, the Ethernet to USB > adapter is not necessary, of course, but still remains convenient when > going back to the office and having to plug back into the wired corporate > network while still keeping connected with the Pi2. For laptops like the > MacBook Air lacking an embedded Ethernet port, such Ethernet adapters would > be necessary to connect to the Pi2 over Ethernet. > > So the challenge is now to find a simple Ethernet to Ethernet network > setup that will work for Windows, OSX and Linux. > Configuring the Pi2 to act as a local DHCP server for this Ethernet link > might be a good starting point. > I already got a similar setup for my little Pi2 cluster. Let's try to see > if I can make this fly... > Yep, it does fly quite well... Martin > Martin > > Martin >> >> >>> Bernhard >>> >>> >>> > >>> > Martin >>> > >>> > >>> > >>> > Bernhard >>> > >>> > >>> > > >>> > > Martin >>> > > >>> > > >>> > > >>> > > >>> > ------------------------------------------------------------------ >>> - ------------ >>> > > >>> > > >>> > > >>> > > _______________________________________________ >>> > > Foam-extend-developers mailing list >>> > > Foa...@li... >>> > <mailto:Foa...@li...> >>> > > https://lists.sourceforge.net/lists/listinfo/foam-extend-develop >>> ers >>> > > >>> > >>> > ------------------------------------------------------------------ >>> - ------------ >>> > _______________________________________________ >>> > Foam-extend-developers mailing list >>> > Foa...@li... >>> > <mailto:Foa...@li...> >>> > https://lists.sourceforge.net/lists/listinfo/foam-extend-developer >>> s >>> > >>> > >>> > >>> > >>> > -- >>> > Martin Beaudoin >>> > >>> > >>> > ---------------------------------------------------------------------- >>> - -------- >>> > >>> > >>> > >>> > _______________________________________________ >>> > Foam-extend-developers mailing list >>> > Foa...@li... >>> > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers >>> > >>> -----BEGIN PGP SIGNATURE----- >>> Comment: GPGTools - https://gpgtools.org >>> >>> iEYEARECAAYFAlYxXi4ACgkQXIMfp1I+9MEjOgCeN0dcd5j9TqScrP5n6zvtBMfV >>> dL0AnAgFDr+5yBuLq1jxJi5H7P2+38Ab >>> =0kAP >>> -----END PGP SIGNATURE----- >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Foam-extend-developers mailing list >>> Foa...@li... >>> https://lists.sourceforge.net/lists/listinfo/foam-extend-developers >>> >> >> >> >> -- >> Martin Beaudoin >> > > > > -- > Martin Beaudoin > -- Martin Beaudoin |
|
From: Martin B. <bea...@gm...> - 2015-10-29 05:32:05
|
On Wed, Oct 28, 2015 at 9:36 PM, Martin Beaudoin <bea...@gm...> wrote: > > > On Wed, Oct 28, 2015 at 7:45 PM, Bernhard Gschaider <bgs...@ic...> > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Am 29.10.15 um 00:12 schrieb Martin Beaudoin: >> >> > > As for using such small systems for the Workshop USB stick, if w >> e can >> > > figure out a way to USB tether a RaspBerry Pi2 with a normal lap >> top + >> > > some kind of terminal app. so we can simply ssh through the USB >> link, >> > > then we could have cheaper solution than the Intel stick. >> > > >> > > Here is a rough estimate of the cost in USD$, based on the units >> I have >> > > bought so far: >> > > >> > > * RaspBerry Pi 2 Model B : 35$ >> > > * 32GB Ultra MicroSDHC Class 10 card: 15$ >> > > * A Raspberry Pi2 case : 10$ >> > > * A USB cable for power and tether : 5$ >> > > >> > > For a total of roughly 65 $USD. >> > > >> > > And a 32GB card is slightly roomy. The OS is free, and the recip >> e to >> > > deploy foam-extend over this device is known. >> > > >> > > And we are still not talking bulk pricing here. I am sure we can >> shave a >> > > few $ if we buy a 100 of those... >> > > >> > > So the only piece of the puzzle remaining is a little bit of sof >> tware >> > > for USB tethering.... >> > > >> > > Maybe we can do all this as well with an Intel Compute stick. Bo >> th >> > > solutions would be way cool... >> > >> > But the ultimate decision is of course with the Workshop organizer >> . >> > Because of course the logistics for the production of USB-keys is >> > already known >> > >> > But lets see if we find something >> > >> > >> > Some other possible avenues to link a Pi2 with a good old >> > Linux/Mac/Windows laptop: >> > >> > * Ethernet to Ethernet using an Ethernet crossover patch cable. >> > Needs an Ethernet port on the laptop, which no longer comes standa >> rd >> > on some laptops (MacBook Air) >> > Probably needs to add some kind of additional network routing to >> > make this work while the laptop is still connected to the OFW wifi >> > hotspot >> >> Something like this >> http://diyhacking.com/connect-raspberry-pi-to-laptop-display/ >> >> What is not funny here is that for every OS setting up the network is >> different (plus that some people might not have the privileges for this) >> > > Yep, not an attractive solution for a whole group of various and different > platforms or OSes. > Too much time will be needed to set this up prior to starting the > trainings and such... > >> >> > * Wifi access >> > We can transform the Pi2 as a Wifi Access point so the laptop can >> > establish a WIFI connection directly with the Pi2. >> > We need to add a decent WIFI USB dongle to the Pi2 (+ ~12 USD$) >> > Having a room full of 10s of little WIFI Access points/routers wou >> ld >> > be a very funny and probably inextricable mess >> >> And every RasPi would have to be setup differently so that it can be >> paired (otherwise Joe will connect to Abduhls RasPi) >> >> Note really feasible >> > > Indeed. > > >> >> > * Serial over USB >> > The laptop would connect unidirectionally the Pi2 using an emulat >> ed >> > serial/terminal console available over one of the 4 USB ports >> > available on the Pi2 >> > Ohhhhhhh, maybe we have something worth exploring here too..... >> > Kermit anyone? LOL :):) >> >> http://workshop.raspberrypiaustralia.com/usb/ttl/connecting/2014/08/31/0 >> 1-connecting-to-raspberry-pi-via-usb/ >> <http://workshop.raspberrypiaustralia.com/usb/ttl/connecting/2014/08/31/01-connecting-to-raspberry-pi-via-usb/> >> >> Needs additional hardware and the correct cable >> >> > And we cannot run paraview over a mere ASCII console.... Not a great all > around solution. > > >> > * TCP/IP over USB >> > Looks like we need a special kind of cable for this >> > Still investigating.... >> > >> > But definitely, the USB port is probably the most universal connector >> > still available on a multitude of hardware platforms. Let's find a way >> > to talk to this little guy... >> >> I can't think of another way than the ones you listed. To be honest: >> none of them convinces me when I think of the support problems they're >> going to raise. But I'll keep looking >> >> > Yup, we need something easy to setup, and based on some really common > laptop applications like Putty or MobaXterm for Windows, or X Windows over > ssh for OSX or Linux. The complexity of this setup has to remain on the Pi2 > side so we can configure it correctly ourselves prior to distributing these > little beast... > > Going back hunting... > > Looks like there is no way around it, a USB to USB connection requires a fancy USB Bridge cable with some electronics embedded in the cable. Basically, USB cannot do host to host without this kind of device. See here for the details : http://www.linux-usb.org/usbnet/ So it looks to me the best and most flexible option now becomes using the Pi2 Ethernet port + short Ethernet cable + Ethernet to USB adapter. I can find on Amazon some USB 2.0 to 10/100 Fast Ethernet LAN Wired Network Adapter for about 20 $USD. A short flat Ethernet cable can be bought for about 1$. Still bearable. For laptops having there own embedded Ethernet port, the Ethernet to USB adapter is not necessary, of course, but still remains convenient when going back to the office and having to plug back into the wired corporate network while still keeping connected with the Pi2. For laptops like the MacBook Air lacking an embedded Ethernet port, such Ethernet adapters would be necessary to connect to the Pi2 over Ethernet. So the challenge is now to find a simple Ethernet to Ethernet network setup that will work for Windows, OSX and Linux. Configuring the Pi2 to act as a local DHCP server for this Ethernet link might be a good starting point. I already got a similar setup for my little Pi2 cluster. Let's try to see if I can make this fly... Martin Martin > > >> Bernhard >> >> >> > >> > Martin >> > >> > >> > >> > Bernhard >> > >> > >> > > >> > > Martin >> > > >> > > >> > > >> > > >> > ------------------------------------------------------------------ >> - ------------ >> > > >> > > >> > > >> > > _______________________________________________ >> > > Foam-extend-developers mailing list >> > > Foa...@li... >> > <mailto:Foa...@li...> >> > > https://lists.sourceforge.net/lists/listinfo/foam-extend-develop >> ers >> > > >> > >> > ------------------------------------------------------------------ >> - ------------ >> > _______________________________________________ >> > Foam-extend-developers mailing list >> > Foa...@li... >> > <mailto:Foa...@li...> >> > https://lists.sourceforge.net/lists/listinfo/foam-extend-developer >> s >> > >> > >> > >> > >> > -- >> > Martin Beaudoin >> > >> > >> > ---------------------------------------------------------------------- >> - -------- >> > >> > >> > >> > _______________________________________________ >> > Foam-extend-developers mailing list >> > Foa...@li... >> > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers >> > >> -----BEGIN PGP SIGNATURE----- >> Comment: GPGTools - https://gpgtools.org >> >> iEYEARECAAYFAlYxXi4ACgkQXIMfp1I+9MEjOgCeN0dcd5j9TqScrP5n6zvtBMfV >> dL0AnAgFDr+5yBuLq1jxJi5H7P2+38Ab >> =0kAP >> -----END PGP SIGNATURE----- >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Foam-extend-developers mailing list >> Foa...@li... >> https://lists.sourceforge.net/lists/listinfo/foam-extend-developers >> > > > > -- > Martin Beaudoin > -- Martin Beaudoin |
|
From: Martin B. <bea...@gm...> - 2015-10-29 01:36:52
|
On Wed, Oct 28, 2015 at 7:45 PM, Bernhard Gschaider <bgs...@ic...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 29.10.15 um 00:12 schrieb Martin Beaudoin: > > > > As for using such small systems for the Workshop USB stick, if w > e can > > > figure out a way to USB tether a RaspBerry Pi2 with a normal lap > top + > > > some kind of terminal app. so we can simply ssh through the USB > link, > > > then we could have cheaper solution than the Intel stick. > > > > > > Here is a rough estimate of the cost in USD$, based on the units > I have > > > bought so far: > > > > > > * RaspBerry Pi 2 Model B : 35$ > > > * 32GB Ultra MicroSDHC Class 10 card: 15$ > > > * A Raspberry Pi2 case : 10$ > > > * A USB cable for power and tether : 5$ > > > > > > For a total of roughly 65 $USD. > > > > > > And a 32GB card is slightly roomy. The OS is free, and the recip > e to > > > deploy foam-extend over this device is known. > > > > > > And we are still not talking bulk pricing here. I am sure we can > shave a > > > few $ if we buy a 100 of those... > > > > > > So the only piece of the puzzle remaining is a little bit of sof > tware > > > for USB tethering.... > > > > > > Maybe we can do all this as well with an Intel Compute stick. Bo > th > > > solutions would be way cool... > > > > But the ultimate decision is of course with the Workshop organizer > . > > Because of course the logistics for the production of USB-keys is > > already known > > > > But lets see if we find something > > > > > > Some other possible avenues to link a Pi2 with a good old > > Linux/Mac/Windows laptop: > > > > * Ethernet to Ethernet using an Ethernet crossover patch cable. > > Needs an Ethernet port on the laptop, which no longer comes standa > rd > > on some laptops (MacBook Air) > > Probably needs to add some kind of additional network routing to > > make this work while the laptop is still connected to the OFW wifi > > hotspot > > Something like this > http://diyhacking.com/connect-raspberry-pi-to-laptop-display/ > > What is not funny here is that for every OS setting up the network is > different (plus that some people might not have the privileges for this) > Yep, not an attractive solution for a whole group of various and different platforms or OSes. Too much time will be needed to set this up prior to starting the trainings and such... > > > * Wifi access > > We can transform the Pi2 as a Wifi Access point so the laptop can > > establish a WIFI connection directly with the Pi2. > > We need to add a decent WIFI USB dongle to the Pi2 (+ ~12 USD$) > > Having a room full of 10s of little WIFI Access points/routers wou > ld > > be a very funny and probably inextricable mess > > And every RasPi would have to be setup differently so that it can be > paired (otherwise Joe will connect to Abduhls RasPi) > > Note really feasible > Indeed. > > > * Serial over USB > > The laptop would connect unidirectionally the Pi2 using an emulat > ed > > serial/terminal console available over one of the 4 USB ports > > available on the Pi2 > > Ohhhhhhh, maybe we have something worth exploring here too..... > > Kermit anyone? LOL :):) > > http://workshop.raspberrypiaustralia.com/usb/ttl/connecting/2014/08/31/0 > 1-connecting-to-raspberry-pi-via-usb/ > > Needs additional hardware and the correct cable > > And we cannot run paraview over a mere ASCII console.... Not a great all around solution. > > * TCP/IP over USB > > Looks like we need a special kind of cable for this > > Still investigating.... > > > > But definitely, the USB port is probably the most universal connector > > still available on a multitude of hardware platforms. Let's find a way > > to talk to this little guy... > > I can't think of another way than the ones you listed. To be honest: > none of them convinces me when I think of the support problems they're > going to raise. But I'll keep looking > > Yup, we need something easy to setup, and based on some really common laptop applications like Putty or MobaXterm for Windows, or X Windows over ssh for OSX or Linux. The complexity of this setup has to remain on the Pi2 side so we can configure it correctly ourselves prior to distributing these little beast... Going back hunting... Martin > Bernhard > > > > > > Martin > > > > > > > > Bernhard > > > > > > > > > > Martin > > > > > > > > > > > > > > ------------------------------------------------------------------ > - ------------ > > > > > > > > > > > > _______________________________________________ > > > Foam-extend-developers mailing list > > > Foa...@li... > > <mailto:Foa...@li...> > > > https://lists.sourceforge.net/lists/listinfo/foam-extend-develop > ers > > > > > > > ------------------------------------------------------------------ > - ------------ > > _______________________________________________ > > Foam-extend-developers mailing list > > Foa...@li... > > <mailto:Foa...@li...> > > https://lists.sourceforge.net/lists/listinfo/foam-extend-developer > s > > > > > > > > > > -- > > Martin Beaudoin > > > > > > ---------------------------------------------------------------------- > - -------- > > > > > > > > _______________________________________________ > > Foam-extend-developers mailing list > > Foa...@li... > > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > > > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - https://gpgtools.org > > iEYEARECAAYFAlYxXi4ACgkQXIMfp1I+9MEjOgCeN0dcd5j9TqScrP5n6zvtBMfV > dL0AnAgFDr+5yBuLq1jxJi5H7P2+38Ab > =0kAP > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------------ > _______________________________________________ > Foam-extend-developers mailing list > Foa...@li... > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > -- Martin Beaudoin |
|
From: Bernhard G. <bgs...@ic...> - 2015-10-28 23:46:02
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 29.10.15 um 00:12 schrieb Martin Beaudoin: > > As for using such small systems for the Workshop USB stick, if w e can > > figure out a way to USB tether a RaspBerry Pi2 with a normal lap top + > > some kind of terminal app. so we can simply ssh through the USB link, > > then we could have cheaper solution than the Intel stick. > > > > Here is a rough estimate of the cost in USD$, based on the units I have > > bought so far: > > > > * RaspBerry Pi 2 Model B : 35$ > > * 32GB Ultra MicroSDHC Class 10 card: 15$ > > * A Raspberry Pi2 case : 10$ > > * A USB cable for power and tether : 5$ > > > > For a total of roughly 65 $USD. > > > > And a 32GB card is slightly roomy. The OS is free, and the recip e to > > deploy foam-extend over this device is known. > > > > And we are still not talking bulk pricing here. I am sure we can shave a > > few $ if we buy a 100 of those... > > > > So the only piece of the puzzle remaining is a little bit of sof tware > > for USB tethering.... > > > > Maybe we can do all this as well with an Intel Compute stick. Bo th > > solutions would be way cool... > > But the ultimate decision is of course with the Workshop organizer . > Because of course the logistics for the production of USB-keys is > already known > > But lets see if we find something > > > Some other possible avenues to link a Pi2 with a good old > Linux/Mac/Windows laptop: > > * Ethernet to Ethernet using an Ethernet crossover patch cable. > Needs an Ethernet port on the laptop, which no longer comes standa rd > on some laptops (MacBook Air) > Probably needs to add some kind of additional network routing to > make this work while the laptop is still connected to the OFW wifi > hotspot Something like this http://diyhacking.com/connect-raspberry-pi-to-laptop-display/ What is not funny here is that for every OS setting up the network is different (plus that some people might not have the privileges for this) > * Wifi access > We can transform the Pi2 as a Wifi Access point so the laptop can > establish a WIFI connection directly with the Pi2. > We need to add a decent WIFI USB dongle to the Pi2 (+ ~12 USD$) > Having a room full of 10s of little WIFI Access points/routers wou ld > be a very funny and probably inextricable mess And every RasPi would have to be setup differently so that it can be paired (otherwise Joe will connect to Abduhls RasPi) Note really feasible > * Serial over USB > The laptop would connect unidirectionally the Pi2 using an emulat ed > serial/terminal console available over one of the 4 USB ports > available on the Pi2 > Ohhhhhhh, maybe we have something worth exploring here too..... > Kermit anyone? LOL :):) http://workshop.raspberrypiaustralia.com/usb/ttl/connecting/2014/08/31/0 1-connecting-to-raspberry-pi-via-usb/ Needs additional hardware and the correct cable > * TCP/IP over USB > Looks like we need a special kind of cable for this > Still investigating.... > > But definitely, the USB port is probably the most universal connector > still available on a multitude of hardware platforms. Let's find a way > to talk to this little guy... I can't think of another way than the ones you listed. To be honest: none of them convinces me when I think of the support problems they're going to raise. But I'll keep looking Bernhard > > Martin > > > > Bernhard > > > > > > Martin > > > > > > > > > ------------------------------------------------------------------ - ------------ > > > > > > > > _______________________________________________ > > Foam-extend-developers mailing list > > Foa...@li... > <mailto:Foa...@li...> > > https://lists.sourceforge.net/lists/listinfo/foam-extend-develop ers > > > > ------------------------------------------------------------------ - ------------ > _______________________________________________ > Foam-extend-developers mailing list > Foa...@li... > <mailto:Foa...@li...> > https://lists.sourceforge.net/lists/listinfo/foam-extend-developer s > > > > > -- > Martin Beaudoin > > > ---------------------------------------------------------------------- - -------- > > > > _______________________________________________ > Foam-extend-developers mailing list > Foa...@li... > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAlYxXi4ACgkQXIMfp1I+9MEjOgCeN0dcd5j9TqScrP5n6zvtBMfV dL0AnAgFDr+5yBuLq1jxJi5H7P2+38Ab =0kAP -----END PGP SIGNATURE----- |
|
From: Martin B. <bea...@gm...> - 2015-10-28 23:12:52
|
On Wed, Oct 28, 2015 at 3:52 PM, Bernhard Gschaider <bgs...@ic...> wrote: > Am 28.10.15 um 16:07 schrieb Martin Beaudoin: > > > > > > On Wed, Oct 28, 2015 at 9:59 AM, Bernhard Gschaider <bgs...@ic... > > <mailto:bgs...@ic...>> wrote: > > > > > > > How long did compilation take? > > > > > > > > > Not sure. The compilation went over multiple phases while I was > nailing > > > down the compilation recipe. I will push a full recompilation a > little > > > bit later next week, and give you the numbers. For sure, compiling > over > > > 4 cores do help a lot, and the speed of your microSD card do play > a big > > > factor as well. > > > > Because that was one of the reasons why I didn't try it on my RasPis. > > Estimate was that it would take several days. I even thought about > > setting up a virtual machine and cross-compiling (seems that this is > the > > way that packages usually are made for the RasPi) > > > > > > We are not talking multiple days of compilation for sure for a basic > > install. I think it is still within a 24 hours span, but I will have to > > check again. > > That's consistent with my estimate at the time. From what I remember the > RasPi 2 is supposed to be 6 times faster than the original > > > And I chose to reuse as many system ThirdParty packages as possible. So > > I did not recompile gcc nor openmpi. I also skipped the compilation of > > paraview and Qt. But I did compile swak4foam (without a glitch!) > > > > Good to hear > > > As for using such small systems for the Workshop USB stick, if we can > > figure out a way to USB tether a RaspBerry Pi2 with a normal laptop + > > some kind of terminal app. so we can simply ssh through the USB link, > > then we could have cheaper solution than the Intel stick. > > > > Here is a rough estimate of the cost in USD$, based on the units I have > > bought so far: > > > > * RaspBerry Pi 2 Model B : 35$ > > * 32GB Ultra MicroSDHC Class 10 card: 15$ > > * A Raspberry Pi2 case : 10$ > > * A USB cable for power and tether : 5$ > > > > For a total of roughly 65 $USD. > > > > And a 32GB card is slightly roomy. The OS is free, and the recipe to > > deploy foam-extend over this device is known. > > > > And we are still not talking bulk pricing here. I am sure we can shave a > > few $ if we buy a 100 of those... > > > > So the only piece of the puzzle remaining is a little bit of software > > for USB tethering.... > > > > Maybe we can do all this as well with an Intel Compute stick. Both > > solutions would be way cool... > > But the ultimate decision is of course with the Workshop organizer. > Because of course the logistics for the production of USB-keys is > already known > > But lets see if we find something > > Some other possible avenues to link a Pi2 with a good old Linux/Mac/Windows laptop: - Ethernet to Ethernet using an Ethernet crossover patch cable. Needs an Ethernet port on the laptop, which no longer comes standard on some laptops (MacBook Air) Probably needs to add some kind of additional network routing to make this work while the laptop is still connected to the OFW wifi hotspot - Wifi access We can transform the Pi2 as a Wifi Access point so the laptop can establish a WIFI connection directly with the Pi2. We need to add a decent WIFI USB dongle to the Pi2 (+ ~12 USD$) Having a room full of 10s of little WIFI Access points/routers would be a very funny and probably inextricable mess - Serial over USB The laptop would connect unidirectionally the Pi2 using an emulated serial/terminal console available over one of the 4 USB ports available on the Pi2 Ohhhhhhh, maybe we have something worth exploring here too..... Kermit anyone? LOL :):) - TCP/IP over USB Looks like we need a special kind of cable for this Still investigating.... But definitely, the USB port is probably the most universal connector still available on a multitude of hardware platforms. Let's find a way to talk to this little guy... Martin > Bernhard > > > > > > Martin > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > Foam-extend-developers mailing list > > Foa...@li... > > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Foam-extend-developers mailing list > Foa...@li... > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > -- Martin Beaudoin |
|
From: Bernhard G. <bgs...@ic...> - 2015-10-28 19:52:31
|
Am 28.10.15 um 16:07 schrieb Martin Beaudoin: > > > On Wed, Oct 28, 2015 at 9:59 AM, Bernhard Gschaider <bgs...@ic... > <mailto:bgs...@ic...>> wrote: > > > > How long did compilation take? > > > > > > Not sure. The compilation went over multiple phases while I was nailing > > down the compilation recipe. I will push a full recompilation a little > > bit later next week, and give you the numbers. For sure, compiling over > > 4 cores do help a lot, and the speed of your microSD card do play a big > > factor as well. > > Because that was one of the reasons why I didn't try it on my RasPis. > Estimate was that it would take several days. I even thought about > setting up a virtual machine and cross-compiling (seems that this is the > way that packages usually are made for the RasPi) > > > We are not talking multiple days of compilation for sure for a basic > install. I think it is still within a 24 hours span, but I will have to > check again. That's consistent with my estimate at the time. From what I remember the RasPi 2 is supposed to be 6 times faster than the original > And I chose to reuse as many system ThirdParty packages as possible. So > I did not recompile gcc nor openmpi. I also skipped the compilation of > paraview and Qt. But I did compile swak4foam (without a glitch!) > Good to hear > As for using such small systems for the Workshop USB stick, if we can > figure out a way to USB tether a RaspBerry Pi2 with a normal laptop + > some kind of terminal app. so we can simply ssh through the USB link, > then we could have cheaper solution than the Intel stick. > > Here is a rough estimate of the cost in USD$, based on the units I have > bought so far: > > * RaspBerry Pi 2 Model B : 35$ > * 32GB Ultra MicroSDHC Class 10 card: 15$ > * A Raspberry Pi2 case : 10$ > * A USB cable for power and tether : 5$ > > For a total of roughly 65 $USD. > > And a 32GB card is slightly roomy. The OS is free, and the recipe to > deploy foam-extend over this device is known. > > And we are still not talking bulk pricing here. I am sure we can shave a > few $ if we buy a 100 of those... > > So the only piece of the puzzle remaining is a little bit of software > for USB tethering.... > > Maybe we can do all this as well with an Intel Compute stick. Both > solutions would be way cool... But the ultimate decision is of course with the Workshop organizer. Because of course the logistics for the production of USB-keys is already known But lets see if we find something Bernhard > > Martin > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Foam-extend-developers mailing list > Foa...@li... > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > |
|
From: Martin B. <bea...@gm...> - 2015-10-28 15:08:14
|
On Wed, Oct 28, 2015 at 9:59 AM, Bernhard Gschaider <bgs...@ic...> wrote: > > > How long did compilation take? > > > > > > Not sure. The compilation went over multiple phases while I was nailing > > down the compilation recipe. I will push a full recompilation a little > > bit later next week, and give you the numbers. For sure, compiling over > > 4 cores do help a lot, and the speed of your microSD card do play a big > > factor as well. > > Because that was one of the reasons why I didn't try it on my RasPis. > Estimate was that it would take several days. I even thought about > setting up a virtual machine and cross-compiling (seems that this is the > way that packages usually are made for the RasPi) > > We are not talking multiple days of compilation for sure for a basic install. I think it is still within a 24 hours span, but I will have to check again. And I chose to reuse as many system ThirdParty packages as possible. So I did not recompile gcc nor openmpi. I also skipped the compilation of paraview and Qt. But I did compile swak4foam (without a glitch!) As for using such small systems for the Workshop USB stick, if we can figure out a way to USB tether a RaspBerry Pi2 with a normal laptop + some kind of terminal app. so we can simply ssh through the USB link, then we could have cheaper solution than the Intel stick. Here is a rough estimate of the cost in USD$, based on the units I have bought so far: - RaspBerry Pi 2 Model B : 35$ - 32GB Ultra MicroSDHC Class 10 card: 15$ - A Raspberry Pi2 case : 10$ - A USB cable for power and tether : 5$ For a total of roughly 65 $USD. And a 32GB card is slightly roomy. The OS is free, and the recipe to deploy foam-extend over this device is known. And we are still not talking bulk pricing here. I am sure we can shave a few $ if we buy a 100 of those... So the only piece of the puzzle remaining is a little bit of software for USB tethering.... Maybe we can do all this as well with an Intel Compute stick. Both solutions would be way cool... Martin |
|
From: Bernhard G. <bgs...@ic...> - 2015-10-28 13:59:57
|
Am 28.10.15 um 01:42 schrieb Martin Beaudoin: > > > On Tue, Oct 27, 2015 at 7:59 PM, Bernhard Gschaider <bgs...@ic... > <mailto:bgs...@ic...>> wrote: > > Am 24.10.15 um 22:21 schrieb Martin Beaudoin: > > Foam-extend over Raspberry Pi2, a very small 32-bit machine (about the > > size of a credit card). > > > > http://foam-extend.sourceforge.net/CDash/index.php?project=foam-extend > -3.2&date=20151024 > <http://foam-extend.sourceforge.net/CDash/index.php?project=foam-extend > -3.2&date=20151024> > > Cooooool. I thought about trying this on my first RasPi two years ago > but it would have taken too long and it was earmarked for another projec > t > > > I got hooked myself when the 4-core version started shipping. I was tempted. But my two have sufficient computational power for what I currently need them to do > And I also wanted to show my 18-yo techie son how easy it was to build a > totally functional mini =-cluster with credit-card size computers, > running full fledge scientific apps like foam-extend, paraview, etc. He > wants to go in engineering like daddy and mommy, so I am trying pique > his interest for CFD, just in case... :) You're trying to build a CFD-dynasty > > That machine is running on Arch Linux, an OS I am starting to like ver > y > > much. > > > > The failed tests either took too long, or ran out of memory when runni > ng > > in parallel (only 1Gb per node). :) > > How long did compilation take? > > > Not sure. The compilation went over multiple phases while I was nailing > down the compilation recipe. I will push a full recompilation a little > bit later next week, and give you the numbers. For sure, compiling over > 4 cores do help a lot, and the speed of your microSD card do play a big > factor as well. Because that was one of the reasons why I didn't try it on my RasPis. Estimate was that it would take several days. I even thought about setting up a virtual machine and cross-compiling (seems that this is the way that packages usually are made for the RasPi) > > I will do the same exercise on Raspbian, which is usually the default > OS > > used on those tiny machines. > > Then I will propose a merge request if you are interested to add this > > platform to foam-extend. I will handle the support if you do accept th > e > > merge. > > > > I am currently assembling a small 5 nodes Raspberry Pi2 cluster. 1 > > master node + 4 slaves. 5 x 4 distributed cores. > > Communicating over a small 100 Gbps Ethernet switch. Very classic desi > gn. > > > > I know, I have access to a 100 TFlops system back at the office, so wh > y > > bother... > > Because you can. That's reason enough > > > Yup. Bragging right... :) > > > > > Let's just say I want to explore new ideas, from a significantly > > different hardware perspective... > > I once thought that such a thing would be the next step from the > Workshop-USB-stick. But apart from the cost there are practical issues > (nobody brings a keyboard and a monitor to the Workshop. If something > like > https://www-ssl.intel.com/content/www/us/en/compute-stick/intel-compute- > stick.html > <https://www-ssl.intel.com/content/www/us/en/compute-stick/intel-compute- > stick.html> > could be plugged into a laptop and accessed via a terminal then we'd > have a winner) > > At ~140 $CDN (~100 $US or 2 Euros :)~ ....) the device is not cheap... > > But if we can get a sponsorship from Intel, I will certainly offer the > time to set it up, and burn the disks using my cluster (the big one I > mean...) > > I might even want to start early, this little device is certainly > interesting, and the specs are very close to the pi2 I am currently > using.... The Problem is in my opinion the HDMI because I see no way to reasonably do anything with this in the Workshop training-scenario. Ideal would be a USB-stick that you can access from the Notebook with a Terminal program (basically instead of a virtual machine an independent computer). I thought https://www.wikiwand.com/en/Intel_Edison is a possibilit but it seems: No Bernhard > > Tell me what you think... > > Martin > > > Bernhard > > > > Am 24.10.15 um 22:21 schrieb Martin Beaudoin: > > -3.2&date=20151024 > > Cooooool. I thought about trying this on my first RasPi two years ago > but it would have taken too long and it was earmarked for another projec > t > > > y > > ng > > > How long did compilation take? > > > OS > > e > > gn. > > y > > > Because you can. That's reason enough > > > > I once thought that such a thing would be the next step from the > Workshop-USB-stick. But apart from the cost there are practical issues > (nobody brings a keyboard and a monitor to the Workshop. If something > like > https://www-ssl.intel.com/content/www/us/en/compute-stick/intel-compute- > stick.html > <https://www-ssl.intel.com/content/www/us/en/compute-stick/intel-compute- > stick.html> > could be plugged into a laptop and accessed via a terminal then we'd > have a winner) > > Bernhard > > > Enigmail > > ------------------------------------------------------------------------------ > _______________________________________________ > Foam-extend-developers mailing list > Foa...@li... > <mailto:Foa...@li...> > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > > > > > -- > Martin Beaudoin > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Foam-extend-developers mailing list > Foa...@li... > https://lists.sourceforge.net/lists/listinfo/foam-extend-developers > |
|
From: Bernhard G. <bgs...@ic...> - 2015-10-28 00:00:08
|
Am 24.10.15 um 22:21 schrieb Martin Beaudoin: > Foam-extend over Raspberry Pi2, a very small 32-bit machine (about the > size of a credit card). > > http://foam-extend.sourceforge.net/CDash/index.php?project=foam-extend -3.2&date=20151024 Cooooool. I thought about trying this on my first RasPi two years ago but it would have taken too long and it was earmarked for another projec t > That machine is running on Arch Linux, an OS I am starting to like ver y > much. > > The failed tests either took too long, or ran out of memory when runni ng > in parallel (only 1Gb per node). :) How long did compilation take? > I will do the same exercise on Raspbian, which is usually the default OS > used on those tiny machines. > Then I will propose a merge request if you are interested to add this > platform to foam-extend. I will handle the support if you do accept th e > merge. > > I am currently assembling a small 5 nodes Raspberry Pi2 cluster. 1 > master node + 4 slaves. 5 x 4 distributed cores. > Communicating over a small 100 Gbps Ethernet switch. Very classic desi gn. > > I know, I have access to a 100 TFlops system back at the office, so wh y > bother... Because you can. That's reason enough > Let's just say I want to explore new ideas, from a significantly > different hardware perspective... I once thought that such a thing would be the next step from the Workshop-USB-stick. But apart from the cost there are practical issues (nobody brings a keyboard and a monitor to the Workshop. If something like https://www-ssl.intel.com/content/www/us/en/compute-stick/intel-compute- stick.html could be plugged into a laptop and accessed via a terminal then we'd have a winner) Bernhard Am 24.10.15 um 22:21 schrieb Martin Beaudoin: -3.2&date=20151024 Cooooool. I thought about trying this on my first RasPi two years ago but it would have taken too long and it was earmarked for another projec t y ng How long did compilation take? OS e gn. y Because you can. That's reason enough I once thought that such a thing would be the next step from the Workshop-USB-stick. But apart from the cost there are practical issues (nobody brings a keyboard and a monitor to the Workshop. If something like https://www-ssl.intel.com/content/www/us/en/compute-stick/intel-compute- stick.html could be plugged into a laptop and accessed via a terminal then we'd have a winner) Bernhard Enigmail |
|
From: Martin B. <bea...@gm...> - 2015-10-27 23:33:29
|
Foam-extend over Raspberry Pi2, a very small 32-bit machine (about the size of a credit card). http://foam-extend.sourceforge.net/CDash/index.php?project=foam-extend-3.2&date=20151024 That machine is running on Arch Linux, an OS I am starting to like very much. The failed tests either took too long, or ran out of memory when running in parallel (only 1Gb per node). :) I will do the same exercise on Raspbian, which is usually the default OS used on those tiny machines. Then I will propose a merge request if you are interested to add this platform to foam-extend. I will handle the support if you do accept the merge. I am currently assembling a small 5 nodes Raspberry Pi2 cluster. 1 master node + 4 slaves. 5 x 4 distributed cores. Communicating over a small 100 Gbps Ethernet switch. Very classic design. I know, I have access to a 100 TFlops system back at the office, so why bother... Let's just say I want to explore new ideas, from a significantly different hardware perspective... Martin |
3 messages has been excluded from this view by a project administrator.