Open kyletreece opened 5 years ago
Hi there,
Maybe with a bit more details on what you plan to implement I could help you more? Basically in GPUSPH you have physparams and simparams which define the simulation and physical parameters, that you can modify through XProblem. If you want to add a new field (like a scalar concentration for example) you'll have to create a new buffer, on the host and on the device. You can use one of the existing buffers as an example (for instance eulerVel). You'll initialise this buffer on the host side (using initializeParticles for instance), and then the data will be copied on the device to be used in kernels. If you look at how things are done at the moment, you'll see that the time scheme is handled by the function runSimulation in GPUSPH.cc, which calls workers in GPUWorkers.cc, and then these workers launch kernels on the device (defined in src/cuda/* files). So you'll need to follow this structure to use the newly defined buffer.
I suggest you work on the branch next (the future 5.0) for your developments since it has undergone some major changes compared to master (version 4.1).
I hope this helps, Agnès
Hi @agnesLeroy ,
Thank you for such a speedy response! Your input is extremely useful and is the exact information I was looking for! I am excited to dig more into the workflow you explained and better understand the system as a whole, and I will definitely start working with and reviewing the next branch.
To answer your question, right now I am looking to add temperature as a new physical parameter and implement simple temperature conduction between particles. I think the workflow you explained covers this change, but if you have any other specific advice for this case I would greatly appreciate it!
Another question relating to the physical parameters, are the expected units defined anywhere? Looking in physicalparams.h I am not seeing units specified. One specific parameter I am a bit confused on is Kinematic Viscosity, as after reviewing a few example problems it seems to vary for what I assume is supposed to be water. StillWater.cu uses 3.0e-2 and has 1.0e-6 commented while Bubble.cu uses 3.5e-5, but both are using the DYNAMICVISC framework setting.
As always, your response and guidance is much appreciated!
Hello @kyletreece
we actually have an implementation of the heat equation in a development branch of GPUSPH, but it was based off a very old version, so one of our collaborators is now porting it to next
; hopefully it will be mature enough for integration soon.
Concerning the viscous model, the kinematicvisc member of physparams is the kinematic viscosity (SI units: m²/s). The KINEMATICVISC and DYNAMICVISC names are a bit improper, but essentially they refer to different implementation of the Morris (1997) viscous model:
In the next
branch, these legacy specifications of the viscous model have been deprecated in favour of a more detailed specification, that allows you to separate the laminar viscous model, averaging operator, turbulence model, rheology (currently only Newtonian is in in next
, but generalized Newtonian models such as Bingham and Herschel–Bulkely are in the works), as well as the preference for kinematic or dynamic viscosity as computational variable.
Hi @Oblomov ,
Thank you for your reply, that is exciting to hear about the heat equation in the next release! Is there an estimate of when V5.0 will be released, including that heat equation implementation? Also, you mentioned it was an old version, what version is that exactly? Would you mind pointing me towards your references for it?
Thank you for the clarification on the current and future viscosity model implementation. Like @agnesLeroy mentioned, it sounds like working in the next branch is the way to go!
Hello @kyletreece
v5 is a few months away still, but a preliminary implementation of thermal re-implemented on top of next
will be merged into next
itself probably within the next month. For the old (internal) implementation, it was based off version 4.1, and a recent reference (including thermal as well as several other experimental GPUSPH features, which will also be merged into next
in the upcoming months) would be Zago et al, AoG 2018.
As soon as the new thermal model is merged into next
, we'll let you know so you can help us debug it ;-)
Hi @Oblomov
That's great to hear about the preliminary implementation in such a short time frame! I will definitely keep an eye out, and would very much appreciate being notified once it is implemented! I would also be happy to provide whatever feedback I can as well!
Thank you very much!
Hi @Oblomov , just refreshing this thread. Is there any update on the preliminary temperature implementation you mentioned previously? I haven't seen any commits to the next branch at least that seem to include it. Still excited to try it out once it's available!
Hello again @agnesLeroy ,
Thank you again for your responses on my previous issue, your help was invaluable and has really helped me get started using this great tool! I am hoping you or someone else can help me with another question.
I would like to add some additional physical parameters/properties and the corresponding equations to be solved, and would like some guidance on where to start. I've seen issue #23 regarding adding particle temperature, and while this is helpful I was wondering if I could get some additional guidance and tips on which pieces of the code I should modify to include new properties and equations. Also, since the particle temperature issue #23 was from 2017, I would like to confirm that the response is still true with the current version of GPUSPH.
Thank you in advance for your response!