Dear Aleksandr, On 18:54 Wed 23 Mar , Aleksandr Sofienko wrote: > You say "at least classes". Could I ask your opinion, your vision of > it?
Depending on the complexity and capability of the code I'd either like to see the resulting code to be integrated as an example into LibGeoDecomp or as a stand-alone code using LibGeoDecomp. > Is it some library? What API do you want? The primary purpose of this project from my point of view would be to carry out simulations with a text file as an input and with the output forming the basis for a visualization. Making the code usable as a library with a well-defined API should in my eyes be a lower priority. > Now I can distinguish next parts: > > input (from text file) > > output (make visualisation ) > > simple forms as a base > class sphere > fields for coordinates and other required characteristics > methods > calculate the next position in space > checking collisions > calculate collisions > > class tetrahedron > the same > > class force > > class Scene > list of objects > method to render the whole scene ( with LibGeoDecomp ) > > I suppose all these classes(sphere, tetrahedron) will be derived from > abstract base classes Shape. This looks about right. I'd add that the class force might need multiple alternative implementations, depending on the integration scheme. We can start with a simple linear dashpot and then see if that's sufficient. It will be sufficient at least for the start. > I think about Constructor for more complex objects. (simply to group > several tetrahedrons into a one solid body) > It's ideas at first glance. Maybe you want something else os something > different. Please share with me. I was thinking about such a group object as well. It would be an elegant way of getting the ability to simulate more complex scenes with relatively simple code. Good thinking! > Another question is how much time does each part require? > It's difficult to me to give time estimates, because it depends from your > expectations. This depends more on your own proficiency and goals than on my expectation. My suggestion: come up with a list of methods required for all objects and rate their relative complexity (e.g. on a scale from 0 to 10). Use that as a basis when estimating the time budget per component. When setting up the mile stones try to find an incremental order that gives you a working system quickly (e.g. first milestone: have a model of interacting spheres with text file output), then add more features with subsequent milestones (e.g. proper visualization, more complex objects, text file input). This way coding will be more fun (you'll have a functional code for most of the time) and my experience is that this leads to better code. Also reserve time in the beginning for learning more about HPX and LibGeoDecomp and some time in the end for documentation. Kind regards -Andreas -- ========================================================== Andreas Schäfer HPC and Grid Computing Department of Computer Science 3 Friedrich-Alexander-Universität Erlangen-Nürnberg, Germany +49 9131 85-27910 PGP/GPG key via keyserver http://www.libgeodecomp.org ========================================================== (\___/) (+'.'+) (")_(") This is Bunny. Copy and paste Bunny into your signature to help him gain world domination!
signature.asc
Description: Digital signature
_______________________________________________ hpx-users mailing list [email protected] https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
