Greets! It’s been a very long time since anything has been posted here. Did the poster go postal? Hehehe.

Well, things have been quiet here but not forgotten. As for EarthJet, the target date is end of the year.

I’ve been working with various implementations and versions of the base code for improvements and efficiencies.  The front-end will be run on .Net while the back-end (base code) will run natively. So far I’ve managed to provide for variable sized particles without too much performance loss. In the midst of the next computer revolution, another important factor I’ve been delving at is that the base code must run multi-core. What would a DEM program look like if it only ran on a single processor? So, the first struggle I’m combating is the choice of an API, runtime, etc.  needed to have EarthJet running on a multi-core processor. If you are computer literate, you’d know what I mean.  Most programming languages are suited only for single-core and when faced with a means of a language well suited for the new revolution you’re at a crossroads with the present language. What will I do? Where will I go? Either I stay with the current language and use ingenuous methods for multi-threading or I re-write everything in Erlang, F#, O’Caml, Haskell, C#’s TPL or MPI or OpenMP… Well, it would have to be a high-performance language similar to C++. Cilk++ is one I’m keeping an eye on.

Whatever the direction, it will eventually work itself out. The end product is one bad boy that runs efficiently using whatever means to fulfill the product specs.

I’ll write some more about the dilemma of a “want to stay mainstream” software developer.

Frank