OpenPixi

Dear Kaivan, thanks for your interest in our project. Unfortunately, this year the CSE umbrella

It turns out the error were 2 additional final fields that the EMMA instrumentation framework adds on

https://github.com/openpixi/openpixi/issues/63 This is very bad. Since the timestep is 0 we have

This is a short summary of my work so far. I will write a detailed description of my progress on this

It works, good job :-) now we can easily see whether the unit tests are still passing. We can even

I fixed the distributed version: https://github.com/openpixi/openpixi/pull/62 Below you find the

> To satisfy both sides of the argument, I suggest to change the class to not use reflection but

Hello, thank you for providing the steps of the simulation. >Sounds nice! Did I understand you

The recently introduced parser can be fed with the XML file that I have attached to this post. You

Yes, but I have to initialize n particles...otherwise I will have to adjust the number of particles

OpenPixi version 0.5 has been released. It seems this version does not run in a web browser any more,

Hi Friends My problem solved I am grateful of your helps.

Hi guys, I repaired the hardwall boundaries to use the particle's radius when detecting whether

Looks good, so please proceed with your solution. (One thing to note is that the classes created

I thought so :) Anyway the solution 1 is much safer. Thanks Andreas On Thu, Jul 5, 2012 at 2:58 PM,

I merged your pull request #27 and released version 0.4: http://www.openpixi.org/ Am Mittwoch, 27.

I would tend to 2), and try to keep all communication-related stuff somehow together. Also, since

Looks good. One should not forget that also diagonal boundaries would be required (for example for

> 1) [...] Is it possible / likely for solve to use currents from neighboring cells? No, most

Cool, cool, then I think we understand each other :) Right now I am writing a text on which data

Thanks a lot Andreas. I think the fact that we want different grid solvers at the boundary of the

The starting point of the idea was that we already have 2 kinds of "things" that we would

I changed the Java version in the main branch to 1.7, so that further development is not hindered.

I wonder why there are so many merges in the commit history: https://github.com/openpixi/openpixi/

I also don't think there is a necessity to introduce additional getters. Someone needs to

If you use phi and rho only within the Solver, and never in the grid, they could stay in the solver.

Since there is no active development on JavaPlot and it is also not yet in the Maven repository, I

Here is the link to the library suggested by Jan: http://jcommander.org/

Yes. I wanted to test the case of a new developer importing the project for the first time, without

I do not really get what for is the section [output] in your example doing but maybe it is not