{"action":"created","issue":{"url":"https://api.github.com/repos/geodynamics/aspect/issues/622","labels_url":"https://api.github.com/repos/geodynamics/aspect/issues/622/labels{/name}","comments_url":"https://api.github.com/repos/geodynamics/aspect/issues/622/comments","events_url":"https://api.github.com/repos/geodynamics/aspect/issues/622/events","html_url":"https://github.com/geodynamics/aspect/issues/622","id":108655028,"number":622,"title":"[Discussion] Activate tracers","user":{"login":"gassmoeller","id":7582930,"avatar_url":"https://avatars.githubusercontent.com/u/7582930?v=3","gravatar_id":"","url":"https://api.github.com/users/gassmoeller","html_url":"https://github.com/gassmoeller","followers_url":"https://api.github.com/users/gassmoeller/followers","following_url":"https://api.github.com/users/gassmoeller/following{/other_user}","gists_url":"https://api.github.com/users/gassmoeller/gists{/gist_id}","starred_url":"https://api.github.com/users/gassmoeller/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gassmoeller/subscriptions","organizations_url":"https://api.github.com/users/gassmoeller/orgs","repos_url":"https://api.github.com/users/gassmoeller/repos","events_url":"https://api.github.com/users/gassmoeller/events{/privacy}","received_events_url":"https://api.github.com/users/gassmoeller/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-09-28T13:11:18Z","updated_at":"2015-10-22T08:26:15Z","closed_at":null,"body":"I open this issue to provide an open discussion page for the process of implementing more active particles in ASPECT. Several people have told me over the last months that they would appreciate a more active particle system, if only to check for the difference between the compositional field advection and particle advection mechanisms, or to reproduce benchmarks that rely on particles. \r\n\r\nMost of the necessary pieces for this should already be in place with #411, but of course the most important part would be a system to interpolate tracer properties back onto the finite-element mesh. Before @egpuckett or myself go ahead with anything (maybe something very simple as a start), I would like to discuss the design of this interpolation. In essence, I would imagine (pseudo)-function calls like the following to be available for plugins that would like to use the particle system:\r\n\r\n`std::vector<double> properties_on_point =\r\nparticle_postprocessor->get_particle_world().map_properties_onto_point(cell_reference,position)`\r\n\r\nor\r\n\r\n`std::vector<std::vector<double> > properties_at_quadrature_points =\r\nget_particles->get_particle_world().map_properties_onto_quadrature_points(cell_reference)`\r\n\r\nBut how do we implement this best inside of the Particle code? Since there are different preferred implementations of this interpolation, a flexible system of one interface class and several derived classes seems reasonable. But should this be designed in the way of the usual ASPECT plugin structure to allow people the largest flexibility to add mappings with own input parameters? Or would it be more reasonable to keep it a bit more hidden? I feel like this interpolation is more like the different solver schemes that also do not offer a plugin architecture. The benefit of a purely internal base_class/derived_class system would be that it would be easier to eventually move the code into deal.II, if we ever decide to go into that direction.\r\n\r\nI would appreciate comments and opinions."},"comment":{"url":"https://api.github.com/repos/geodynamics/aspect/issues/comments/150145131","html_url":"https://github.com/geodynamics/aspect/issues/622#issuecomment-150145131","issue_url":"https://api.github.com/repos/geodynamics/aspect/issues/622","id":150145131,"user":{"login":"cedrict","id":7646114,"avatar_url":"https://avatars.githubusercontent.com/u/7646114?v=3","gravatar_id":"","url":"https://api.github.com/users/cedrict","html_url":"https://github.com/cedrict","followers_url":"https://api.github.com/users/cedrict/followers","following_url":"https://api.github.com/users/cedrict/following{/other_user}","gists_url":"https://api.github.com/users/cedrict/gists{/gist_id}","starred_url":"https://api.github.com/users/cedrict/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cedrict/subscriptions","organizations_url":"https://api.github.com/users/cedrict/orgs","repos_url":"https://api.github.com/users/cedrict/repos","events_url":"https://api.github.com/users/cedrict/events{/privacy}","received_events_url":"https://api.github.com/users/cedrict/received_events","type":"User","site_admin":false},"created_at":"2015-10-22T08:26:15Z","updated_at":"2015-10-22T08:26:15Z","body":"Hi Rene, \r\nI am afraid I cannot comment much on the design/architecture of the code. What I thought we may wish to have a look at is an excerpt of my ELEFANT paper submitted some time ago (and still in Limbo). It concerns the averaging algorithm. There is also a bit on this topic in the pTatin paper (May et al., CMAME 290, 496-523, 2015 - section 3) which may prove useful in the context of second order elements. \r\nCheers, \r\nC.\r\n\r\n![screen shot 2015-10-22 at 10 25 09](https://cloud.githubusercontent.com/assets/7646114/10660370/ca9d636a-78a6-11e5-9f42-ca61aa415c54.png)\r\n![screen shot 2015-10-22 at 10 25 16](https://cloud.githubusercontent.com/assets/7646114/10660372/caa3fca2-78a6-11e5-9525-a9d3963b3d0f.png)\r\n![screen shot 2015-10-22 at 10 25 33](https://cloud.githubusercontent.com/assets/7646114/10660371/ca9dddb8-78a6-11e5-9e36-4c4cfed16bc1.png)\r\n\r\n\r\n"}}