CAELinux 2009
- Alexey Balmashnov
- Offline
- New Member
-
- Posts: 16
- Thank you received: 0
Yep, I know about different support periods. I suspect, that there are other reasons for that, since 8.04 will be supported only 6 month longer than current 9.04.
On the other hand 8.04 announced as the base, but there is also an aim to provide latest versions of software like gmsh, which is slightly outdated even in 9.04... Seems a kind of contradicting

And yes, Salome runs more or less OK on 9.04

- Joël Cugnoni
-
- Offline
- Moderator
-
actually the reason for choosing Ubuntu 8.04 was because of LTS... but the decision was taken nearly one year ago!! In the mean time, I had a lot of work and could not develop "final" versions of CAELinux, but I started to compile & test each codes separatelly on the same Ubuntu 8.04 base.
Now that I have some time to dedicate to CAELinux, I am just re-producing in a clean way all my trials & prototypes on the same Ubuntu 8.04 base to be sure on the result. By the way, it is not too difficult to upgrade a LTS version to the latest release... so once this release is out, I will try testing the upgrade process and the installed software. For 8.04, my only concern is that the kernel & Xorg version are now relativelly old and may not be able to detect all recent hardware... especially graphic cards ... but we will see once it is released!.
For 64bit, the choice is simple: for serious work nowadays, you need more that 2Gb of RAM... and as I cannot find enough time to develop both a 32bit and a 64bit version, I selected the one that I personnally need for my work!
And it is still possible to use the previous 32bit PCLinuxOS based versions (or VMWare version) to run the codes on 32bit computers.
In new PC, 90% of the CPUs are 64bit... it is just a matter of running the recent version on recent hardware and the previous version on older hardware.
For the software, whenever technically possible, I try to compile the latest version from source instead of using relativelly outdated version of the repositories.. with an exception: I use the binary release of Salome-Meca 32 bit developed by EDF as I don't want to spend months trying to recompile it properly.
I hope that it gives you a better view of my very personal development choices and "methodology" which I could summarize by: maximizing efficiency by integrating as many things as I can within strong time contraints!
Best Regards
Joël
Joël Cugnoni - a.k.a admin
www.caelinux.com
- kwou
-
- Offline
- Moderator
-
thank you for sharing your considerations for your 'development route' for CAELinu. I think they are perfectly reasonable. And once again, thank your for all the work done!
** kind regards - kees
Interest: structural mechanics, solar energy (picture at 'my location' shows too little pv panels)
--
kind regards - kees
- Alexey Balmashnov
- Offline
- New Member
-
- Posts: 16
- Thank you received: 0
I see. So, this is more a convenience decision.Hi,
actually the reason for choosing Ubuntu 8.04 was because of LTS... but the decision was taken nearly one year ago!! In the mean time, I had a lot of work and could not develop "final" versions of CAELinux, but I started to compile & test each codes separatelly on the same Ubuntu 8.04 base.
Cool. May you, please, thoroughly document the process, so that others (like myself) may learn from it, and, probably, get involved in the future in the development, e.g. building/testing on i386, trying out other software packages (e.g. freecad) etc?Now that I have some time to dedicate to CAELinux, I am just re-producing in a clean way all my trials & prototypes on the same Ubuntu 8.04 base to be sure on the result. By the way, it is not too difficult to upgrade a LTS version to the latest release... so once this release is out, I will try testing the upgrade process and the installed software. For 8.04, my only concern is that the kernel & Xorg version are now relativelly old and may not be able to detect all recent hardware... especially graphic cards ... but we will see once it is released!.
I see. The thing is, "serious work" often includes prototyping, development of new algorithms, models and similar activities. For example, I performed all activities during my PhD project on system with Core 2 processor and initially with 1GB of RAM, where switching to 64 bit environment, although possible, does not bring any significant benefits. For production-size problems I can imaging the use of more powerful machines and see justification for x64 to be used everywhere, yes.For 64bit, the choice is simple: for serious work nowadays, you need more that 2Gb of RAM... and as I cannot find enough time to develop both a 32bit and a 64bit version, I selected the one that I personnally need for my work!
Using 64-bit also implies using much more memory, just because of architecture.And it is still possible to use the previous 32bit PCLinuxOS based versions (or VMWare version) to run the codes on 32bit computers.
In new PC, 90% of the CPUs are 64bit... it is just a matter of running the recent version on recent hardware and the previous version on older hardware.
Cool, see my words above on documenting the process.For the software, whenever technically possible, I try to compile the latest version from source instead of using relativelly outdated version of the repositories.. with an exception: I use the binary release of Salome-Meca 32 bit developed by EDF as I don't want to spend months trying to recompile it properly.
So, Salome-Meca is just included "as is" in the distribution?
BTW, how many people are currently involved in preparation of the distribution? Do you have contacts with Ubuntu developers? Are there plans to have repository established for programs you build and compile yourself? May be there is already some of documentation on the process, which I missed, if there is any may you point me to that?
Yep, I see and appreciate your choices. Keep up with great job, and many thanks for your effort Joël!I hope that it gives you a better view of my very personal development choices and "methodology" which I could summarize by: maximizing efficiency by integrating as many things as I can within strong time contraints!
Regards,
Alexey
- Joël Cugnoni
-
- Offline
- Moderator
-
Thank you for your interesting comments!
Cool. May you, please, thoroughly document the process, so that others (like myself) may learn from it, and, probably, get involved in the future in the development, e.g. building/testing on i386, trying out other software packages (e.g. freecad) etc?
Actually, I am trying to document all the process of making the distribution. Some parts are lacking though as I am taking some pre-compiled binaries that I prepared in my prototypes... I will append these docs the next time I compile these codes (Code-Aster 64bit with Intel compiler for example...)
About contributions, I really encourage people to develop / update / maintain native Debian / Ubuntu packages , this is probably the most usefull way of efficiently collaborating! But I know that developing packages can be REALLY complicated, so if don't feel comfortable enough, writing a nice installation guide (for example on CAELinux.org wiki) is also really usefull! Finally, from the feedback of the users, it seems that the most important point is examples, tutorials, validation / benchmark and documentation in general. So just using the codes and reporting your discoveries is REALLY appreciated; see tutorials and contributions on caelinux.org:
www.caelinux.org/wiki/index.php/Contrib:Main
www.caelinux.org/wiki/index.php/Doc:CAETutorials
Using 64-bit also implies using much more memory, just because of architecture.
Actually, it is not so much more: in most simulation codes, the floating points (90% of the memory used) are already double precision (64bit) when compiled in 32bit architecture; the only changes are for integers.
So, Salome-Meca is just included "as is" in the distribution?
Not really; Salome-Meca 32 bit binary package is used but it's configuration files & scripts are tuned to work properly in any case and it uses now a custom compiled 64bit version of Aster by default. The modifications are: scripts to accomodate changes of hostname & username, automatic SSH configuration, automatic ASTK configuration, change of preferences to use by default the 64bit Aster solver, integration of the "english HTML docs" into Eficas.
BTW, how many people are currently involved in preparation of the distribution? Do you have contacts with Ubuntu developers? Are there plans to have repository established for programs you build and compile yourself? May be there is already some of documentation on the process, which I missed, if there is any may you point me to that?
At the moment, I am the only developer but I am using a lot of contributions from others, for example: installation doc of Code-Saturne on caelinux.org wiki, posts on code-aster forums / wikis, Salome-Meca binaries developed by Aimery Assire at EDF, Debain/Ubuntu packages (libs & math codes like octave, R...), DEB binary packages for EnGrid, forum & installation docs for Gerris, Calculix, MBDyn etc...
I see my role mostly as an "integrator" of other's work to make an "as coherent as possible" platform. As the process of making a liveDVD cannot be efficiently parallelized, the most usefull contribution from others is to prepare "ready to use" binaries or installation procedures that I can integrate straight forward in the distro. As this is my first steps in the Ubuntu world, I have no contact yet with Ubuntu or its dense community of contributors, but if someone can help me to setup packages, I think that a repository would be a great addition to have smoother updates of the codes!!
For the development of the distribution itself, I am using a very simple method: make a fresh install of the base OS, install all the codes, write scripts to automate configuration, create launchers & tune the environment vars. Then, I create a "remaster" of my install with RemasterSys (a GREAT tool!!) that produces a stand-alone live DVD system out of my installation. Actually, if users want to further customize CAELinux, they can simply install, tune the system (add / remove packages...) and rerun RemasterSys to have a great customized version of their own!
Best Regards
Joël
Joël Cugnoni - a.k.a admin
www.caelinux.com
- Alexey Balmashnov
- Offline
- New Member
-
- Posts: 16
- Thank you received: 0
Thanks again for sharing the information.
I just started to look a bit into the software "packages" provided by various projects and I really confused.
For example, archive with aster (aster-full-src-9.4.0-2.noarch.tar.gz) downloaded from code-aster.org apart from aster itself and relevant tools (some of them are also EDF developed software) contains a bunch of other "source" packages like HDF-library, Python modules and even binary

Similar observations are valid for Salome-Meca 2009.1 provided here in download section... Although, I think I saw an explanation, that it is done this way to provide standalone package, which one may start to use just after simple unpacking in the $HOME directory and executing maintenance script (I "installed" it this way myself). Intention is nice, but this may lead to some confusing things (at least for me), for example, currently on Ubuntu 9.04 I can not use numpy module from Salome, importing which leads to some strange errors about non-availability of shared lapack library, although system-wide Python works just fine...
I understand that it might be time consuming to check, but is it possible to employ as much as possible tools and libraries already available via the repositories? May be you may give some hints, which direction one may to start to digg in for getting an idea about the complexity?