Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding New Properties and Equations to Solve #47

Open
kyletreece opened this issue Jan 23, 2019 · 7 comments
Open

Adding New Properties and Equations to Solve #47

kyletreece opened this issue Jan 23, 2019 · 7 comments

Comments

@kyletreece
Copy link

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!

@agnesLeroy
Copy link

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

@kyletreece
Copy link
Author

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!

@Oblomov
Copy link
Contributor

Oblomov commented Jan 25, 2019

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:

  • KINEMATICVISC is a simplification of the Morris formula in the case of constant kinematic viscosity, with harmonic averaging of the density;
  • DYNAMICVISC assumes that the kinematic viscosity is not constant, and uses arithmetic averaging of the dynamic viscosity of the particles in Morris formula;

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.

@kyletreece
Copy link
Author

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!

@Oblomov
Copy link
Contributor

Oblomov commented Jan 26, 2019

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 ;-)

@kyletreece
Copy link
Author

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!

@kyletreece
Copy link
Author

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants