liblamp-developers — talks regarding planning and development

[liblamp-developers] Test-Driven development

[Stefan N. <noa...@go...>]

Hi all,

Whereas the README suggests to write the Unit tests after you have
written the code, i am just thinking about if it would be better to
write the tests first. I have just experienced that wirting tests
afterwards is less fun than writing them before and making everything
work step by step. What do you think about it? I will try to follow the
"strict" unit testing principles. By the way I add an XML comment to
every method with test-proven behavior. finally everything should
contain such a remark with a reference to the relevant test. when
modifying something covered by a test be sure not to break the test and
to check your new functionality by extending the test cases.

happy coding,

stefan.
-- 
Check out my open source .NET physics library project at
http://liblamp.sourceforge.net

[liblamp-developers] Math.Net numerics and symbolics

[Stefan N. <noa...@go...>]

hi folks,

Just look at this:

http://www.cdrnet.net/projects/nmath/Default.asp?L=EN


I think we could use it as backend for our numerics stuff (of course as
an exchangable module). The symbolics might be helpful for Phy#, too.

What do you think about it?

-- 
Check out my open source .NET physics library project at
http://liblamp.sourceforge.net

[liblamp-developers] Lamp is still alive!

[Stefan N. <noa...@go...>]

Hi everyone,

Due to the A-level exams and my new job as a "real" software developer i
haven't had much time for liblamp in the last few months. However, now i
maneged to keep at least every Sunday (and maybe every Saturday, too)
free for the project. Today i'm going to finish the unit system stuff.
Any ideas on what to do next would be highly appreciated. 

By the way here is a list of possible lamp-based projects that could
become reality in maybe a year or two:

Phy# - .NET language with integrated Lamp framework features
LUI - Lamp User Interface (for professional use)
Lampion - Physics sandbox for students
Lightbulb/Candela - Lamp-based raytracer
<add your own crazy ideas here>

Maybe we could also manage a project meeting some day?

Stefan

-- 
Check out my open source .NET physics library project at
http://liblamp.sourceforge.net

[liblamp-developers] Meeting, books etc.

[Philipp K. <phi...@ph...>]

Hi,


1) Books: I've quite some books over here (about 40-50). I think the best
for beginners are written by "Nolting" and are called "Grundkurs
Theoretische Physik I" and "Grundkurs theoretische Physik II" (thats
mechanics only though). Feel free to come along if you want to (I live about
10minutes away from your school (Theodor Körner Platz 13, 09130 Chemnitz,
Philipp Krone)), if you dont have access to our uni-library. I've some books
about numerical mathematics aswell and one should IMO (in my opinion) read
atleast some pages of these books.


2) If you have a meeting someday, I'd surely take part. Just write it here
and I'll try to make sure to have time.


Philipp

Re: [liblamp-developers] First steps

[Stefan N. <noa...@go...>]

Hi ,

> 1) It surely has to be very abstract, however, this will make
> everything alot more difficult. As I've seen, you've already
> implemented the SI-System. Just want to mention that it's prolly not
> the most used system in the world; the cgs-system is probably used
> more often, especially as it's kinda common in the USA. So we should
> always remember to write the code for all unit-systems (e.g.
> theoretical physicists usually use "god-given units", i.e. c =
> \epsilon_0 = \mu_0 = \hbar = ... = 1, if I remember correctly).

Yes, that's what I discovered, too. Therefore the SI system is just a
module, the framework and the quantity class works with all unit
systems. However, for the implementation of certain objects because not
all unit systems can be converted into each other. I suggest to use the
most appropiate unit system for each problem, for example the use of
sophisticted units makes maxwell's equations look much less complicated.

> 2) Using prewritten units for the numerical part is prolly a good
> first step, however, these units are usually very difficult to use and
> make things much more complex and not always faster. 

We can also make our own numerical backend, but we should provide an
interface to make the numerical part substitutable.

> Solving ODEs will probably be the most difficult stuff and shouldnt be
> underestimated (Euler, Runge-Kutta etc. will NOT work for alot, if not
> most, of the ODEs you'll see in "real physics".)

Yes, i know ^^ That's why I'm going to study computational science to
learn more :)

> 3) Implementing mechanics at first is probably correct, however, I
> would NOT use Lagrange for it, but Hamilton or Hamilton-Jacobi. 

okay.. i don't know hamilton, i will do some research on that
the reason why i suggested lagrange is that you can respect constraints
by transforming everything into virtual coordinates. i also have a plan
how a lagrange-based system might work, however i don't know if it is
still "real" lagrange what i made up.

> Using Hamilton has the big advantage that you can most likely use the
> same classes (if written abstract) for thermodynamics, statistical
> physics and electrodynamics (among others), as all of these fields can
> be described using the basic "field theory". 

wow, that's cool :)

> As Newton, Lagrange and Hamilton is basically the same, atleast from a
> theoretical aspect (the only difference is that it's much more easy to
> solve problems with Lagrange / Hamilton for _us_), it could perhaps
> not make any difference, however, I'm not really into this stuff ATM.

yes, maybe the difference is small, it might me best to implement the
sings that are the basic ideas of all systems in an abstract way whic
makes it easier to vary details.

another thing that i want to mention is that performance is relevant for
us but usability and the representation of physical concepts is more
important.

> you need advise for good books, feel free to ask. If you wanna meet in
> any way: sure! ;)

okay: 

I need some good books, do you know some?

There is a Lamp project meeting every Thursday in our school. I will ask
the other folks next time if they would come to my home (i just moved to
chemnitz lest week) instead after the easter holidays. Maybe you'd like
to come, too?

[liblamp-developers] First steps

[Philipp K. <phi...@ph...>]

Hiho,


Alright, so let's talk english. Didn't know that it's an english
mailinglist, sorry for that.
Just wanna write some thoughts about your last email, Stefan:

1) It surely has to be very abstract, however, this will make everything
alot more difficult. As I've seen, you've already implemented the SI-System.
Just want to mention that it's prolly not the most used system in the world;
the cgs-system is probably used more often, especially as it's kinda common
in the USA. So we should always remember to write the code for all
unit-systems (e.g. theoretical physicists usually use "god-given units", i.e.
c = \epsilon_0 = \mu_0 = \hbar = ... = 1, if I remember correctly).

2) Using prewritten units for the numerical part is prolly a good first
step, however, these units are usually very difficult to use and make things
much more complex and not always faster. I wasn't able to use a lot of these
libraries, as they are usually licensed under the GPL and my thesis programs
are close-sourced, however, the one I have used didnt make things faster and
so I've written most of the stuff myself. I've written quite fast classes
(in FreePascal tho) for vectors and matrices. Solving ODEs will probably be
the most difficult stuff and shouldnt be underestimated (Euler, Runge-Kutta
etc. will NOT work for alot, if not most, of the ODEs you'll see in "real
physics".)

3) Implementing mechanics at first is probably correct, however, I would NOT
use Lagrange for it, but Hamilton or Hamilton-Jacobi. Using Hamilton has the
big advantage that you can most likely use the same classes (if written
abstract) for thermodynamics, statistical physics and electrodynamics (among
others), as all of these fields can be described using the basic "field
theory". As Newton, Lagrange and Hamilton is basically the same, atleast
from a theoretical aspect (the only difference is that it's much more easy
to solve problems with Lagrange / Hamilton for _us_), it could perhaps not
make any difference, however, I'm not really into this stuff ATM.


So far,

Philipp


P.S. If you wanna know more about mentioned stuff, feel free to ask. If you
need advise for good books, feel free to ask. If you wanna meet in any way:
sure! ;)

Re: [liblamp-developers] Introduction mail

[Stefan N. <noa...@go...>]

Hallo Phillip,

Vielen Dank für deine Email.
Normalerweise schreiben wir zwecks nachvollziehbarkeit in den Archiven
von Sourceforge in der Mailingliste auf Englisch, zumindest bei
spezifischen Planungen zum Projekt, damit sie maximalen Nutzen für die
internationale Open-Source-Gemeinde entfalten können. Zum Hallosagen ist
aber Deutsch okay ;-)

Zur Zeit ist das Projekt nicht sehr Weit entwickelt, pläne existieren
Bereits. Es ist zu sagen, dass das Ganze sehr abstrakt und nah an der
physikalischen Betrachtungsweise liegen soll, das fängt bei
Einheitensystemen (bereits implementiert) an, geht über die Beschreibung
physikalischer Modelle und hört bei Lösungsmethoden für ODE noch lange
nicht auf. Modularität wird natürlich eine sehr große Rolle spielen.

Für die Numerik werden wir sicher auf bestehende Libraries
zurückgreifen, sicher hast du da schon erfahrungen, wäre interessant, da
wir demnächst die wichtigsten Elemente der numerischen
Abstraktionsschicht, ich denke da speziell an Vektoren, Matritzen, ODE
usw. Ich denke es wäre auch von Vorteil, mehrere Numerik-Backends zu
unterstützen.

Ich überlegte bereits, ein allwöchentliches Projekttreffen bei mir zu
Hause anstatt wie bisher in der Schule einzurichten, mal sehen.

Physikalisch wollen wor dann als nächstes erstmal klassische Mechanik
machen, aber mit Lagrange. Mittlerweile habe ich schon einen groben
überblick, wie das gehen könnte, immerhin müssen wir das ganze Allgemein
betrachten.

Grüße,
Stefan

On Sat, 2008-03-15 at 16:10 +0100, Philipp Krone wrote:
> Hallo,
> 
> 
> mein Name ist Philipp Krone und ich studiere zur Zeit im 7. Semester
> Physik an der TU-Chemnitz und befasse mich im Rahmen meiner
> Diplomarbeit mit der Simulation von Plasma am PC. Da ich vorhin euren
> BeLL-Vortrag gehört habe und mich die Idee prinzipiell begeistert hat,
> wollte ich mir das ganze Mal anschauen. Sobald Code da ist, werde ich
> ihn mir anschauen und gegebenenfalls Sachen fixen / Vorschläge
> machen / physikalische Hinweise geben / meine Erfahrung mit
> Differentialgleichungslösern (Euler, Runge-Kutta, LSODA, LSODE,
> Leap-Frog, etc) mit Einbringen. Falls ihr direkt irgendwelche Fragen
> habt, steh ich euch auch gern so zur Verfügung.
> 
> Email: phi...@gm...
> msn: do...@do...
> icq: 249784015
> 
> Ich hoffe ich kann euch, falls das erwünscht ist, ein wenig unter die
> Arme greifen, gerade weil ich mich schon seit Jahren mit
> physikalischen Simulationen beschäftige (u.a. auch bei / mit Herrn.
> Dr. Blaudeck).
> 
> 
> Bis dann und mit freundlichen Grüßen
> 
> 
> Philipp Krone
> 
> 
> P.S. Ich selbst programmiere zur Zeit in FreePascal (~ wie Delphi),
> habe jedoch schon diverse Physiktools in C#(.Net) und VB(.Net)
> geschrieben und habe auch sonst schon mit C# und Mono gearbeitet. 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________ liblamp-developers mailing list lib...@li... https://lists.sourceforge.net/lists/listinfo/liblamp-developers

[liblamp-developers] Introduction mail

[Philipp K. <phi...@gm...>]

Hallo,


mein Name ist Philipp Krone und ich studiere zur Zeit im 7. Semester Physik
an der TU-Chemnitz und befasse mich im Rahmen meiner Diplomarbeit mit der
Simulation von Plasma am PC. Da ich vorhin euren BeLL-Vortrag gehört habe
und mich die Idee prinzipiell begeistert hat, wollte ich mir das ganze Mal
anschauen. Sobald Code da ist, werde ich ihn mir anschauen und
gegebenenfalls Sachen fixen / Vorschläge machen / physikalische Hinweise
geben / meine Erfahrung mit Differentialgleichungslösern (Euler,
Runge-Kutta, LSODA, LSODE, Leap-Frog, etc) mit Einbringen. Falls ihr direkt
irgendwelche Fragen habt, steh ich euch auch gern so zur Verfügung.

Email: phi...@gm...
msn: do...@do...
icq: 249784015

Ich hoffe ich kann euch, falls das erwünscht ist, ein wenig unter die Arme
greifen, gerade weil ich mich schon seit Jahren mit physikalischen
Simulationen beschäftige (u.a. auch bei / mit Herrn. Dr. Blaudeck).


Bis dann und mit freundlichen Grüßen


Philipp Krone


P.S. Ich selbst programmiere zur Zeit in FreePascal (~ wie Delphi), habe
jedoch schon diverse Physiktools in C#(.Net) und VB(.Net) geschrieben und
habe auch sonst schon mit C# und Mono gearbeitet.

[liblamp-developers] Classical Mechanics

[Stefan N. <noa...@go...>]

Hi folks,

Kay found that interesting page that I already knew before:

http://www.myphysicslab.com/

On the site the Lagrangian is used for some of the simulations and is
described very well. We could take the description there as kind of
orientation for the concepts in our classical mechanics module which is
the first simulation module I'd like to develop. I think I will create a
diagram or so for that as I already started together with Tim last
thursday, now complete with the information from myphysicslab which
solved most problems we were not sure about.

Things to note:

- We may need a CAS for the partial derivative of the Lagrangian and
other stuff whilst ODE solving must be done numerically (Runge-Kutta)

- Spring forces can also be included in the Lagrangian, only
non-conservative forces (forces which make the system lose mechanical
energy such as friction) must be treated as an extra influx inside the
ODE

Have fun!

-- 
Stefan Noack <noa...@go...>

[liblamp-developers] simple and complex objects

[Stefan N. <noa...@go...>]

Hi folks,

I just wrote down some ideas that i had about the next thing we may
implement. You can also find these notes in the doc/planning directory.
I really like to hear your suggestions :) What do you want to do
differntly or is this okay?

Here is the excerpt:

1.2.: Simple and complex objects

An important idea that should be included is that you can make something
complex from simple elements. However, when simulating the behaviour of
such a combined object only the properties of each element are
important. Altogether they describe the behaviour of the whole system.
The Physical class should of course cover both of these kinds of
objects. Due to their special properties respected and manipulated by
simulators the elementary objects have to be handled in a special way.
This will be done by deriving a class named Simplex from the Physical
class. Evey Physical must provide a list of its elements, which can be
easily be implemented by both the simple objects just returning
themselves and the complex objects concatenating the lists of each
part. The previously mentioned non-static properties are something for
simplexes as they are what simulators can handle. They should provide
definitions for these values but should not store the numbers because
this belongs to the tasks of simulators and frames.

Ideas on how to implement this are also highly appreciated :)

btw: Some tests and xml documentation for the Quantity class and xml
documentation for most other things must be written. Maybe i will do
this tomorrow. Maybe ;-)

-- 
Stefan Noack <noa...@go...>

[liblamp-developers] Basic infrastructure is ready!

[Stefan N. <noa...@go...>]

Hi folks,

Today I got the unit system working as kind of an example for the whole
project. We now have:

- directories for the code
- working Makefiles
- an NUnit test environment
- some tests

and of course the unit system code and a module for the SI unit system.
You may now just download the code from subversion, for example using:

svn co https://liblamp.svn.sourceforge.net/svnroot/liblamp/trunk liblamp

and then run (currently under linux only):

make && make test

Tell me whether it works or not :)
Please read the README ;-)

Now you can also start making lots of suggestions and asking even more
questions. Those of you who didn't subscribe to the list yet should do
it now: https://lists.sourceforge.net/lists/listinfo/liblamp-developers

Remember our project homepage URL: http://liblamp.sourceforge.net

Have fun!
-- 
Stefan Noack <noa...@go...>

[liblamp-developers] Official project start: 1.2.08

[Stefan N. <noa...@go...>]

Hi

I know that some people already subscribed to the list. Therefore i like
to inform you that the project will officially start at the 1st of
February 2008. Until then i will finish the physical quantity and unit
system as described here:

http://liblamp.svn.sourceforge.net/viewvc/liblamp/trunk/doc/planning/framework.txt?view=markup

These things are still quite simple (i wrote the major part of the code
in two days). The main reason for me doing this first part almost alone
before project start is that i have to set up the infrastructure first
but it's hard to find out how Makefiles and NUnit tests work without any
code to make or classes to test. When everything has been set up for
collaborative productive working i will inform you again and also send a
mail to those who did not yet subscribe to this list.

P.S.: I prefer to use the English language for communication through
this list. It is not forbidden to write in German, though and your
requests may even be answered in German. But as i hope that this project
will attract developers form other countries one day written in English
our discussions and documentations will be more helpful for the
international open source community.

[liblamp-developers] Another test

[Stefan N. <noa...@go...>]

This again is a test message.

[liblamp-developers] Test Message

[Stefan N. <noa...@go...>]

This is a test wether the list works.