usnistgov / pfhub

The CHiMaD Phase Field Community Website
https://pages.nist.gov/pfhub
Other
51 stars 41 forks source link

Implement scheme to calculate tip velocity from tip postions #734

Open wd15 opened 6 years ago

wd15 commented 6 years ago

Have the users upload tip position and then calculate the tip velocity in a consistent way on the front end or in Python as a pre-process step.

amjokisaari commented 6 years ago

Hm. I'm on the fence about this and this is something that should be discussed at the workshop. Historically, tip velocity is the metric that is used in papers, so I like to maintain consistency with the literature (also that's how we compare with the analytical solution). However I do see your point about consistent tip velocity calculation. The issue is that if you don't have enough data, the tip velocities will be averaged over too large of a time period...

wd15 commented 6 years ago

@amjokisaari, thanks for the feedback. Yes, let's discuss at the workshop.

wd15 commented 6 years ago

Idea from Tamás Pusztai for calculating the tip speed, radius and position. This would require the full phase field data which we currently don't have. However, in the future we may require the user to upload the full phase field data at given time steps once the MDF data service is integrated.

I have a suggestion for an algorithm that determines the tip properties, such as its position and radius. This works independent of the orientation of the dendrite, so it can be used for the cases when the offset angle theta0 is not zero:

  1. Take the set of (xi,yi) values that define the endpoints of the line segments of the full phi=0 contour. The point with the maximal xi^2+yi^2 value, call it (x0,y0) is the point furthest from the origin, thus, it can be considered as the first approximation of the dendrite tip position. (If you have more than one dendrite arm, you have to make sure that you do not jump between them as you switch to the next output.) As this level of approximation is probably not enough to calculate a meaningful tip velocity, we have to refine it.

  2. Consider the close neighbourhood of the above determined point x0,y0 for further processing. Select all points that are closer to (x0,y0) than some distance d. This distance should be around a few times of the tip radius, and the results should not depend on the choice very much. The next step is to fit a (rotated) parabola on the selected points. This can be done in two ways:

  3. If we assume, that the dendrite arm grows along a straight line from the origin (which should be the direction defined by the offset angle theta0), then all coordinates should be rotated by an angle theta = atan(x0/y0) around the origin (turning the dendrite arm to point upwards along the y axis). Then a simple parabola can be fitted on the points, giving a precise tip position and tip radius at the same time.

  4. If we do not assume growth along a straight line (a general orientation theta0 with non-negligible lattice anisotropy may lead to distorted dendritic shapes), then this rotation angle can also be treated as a fitting parameter.

Edit: the above algorithm does not need the full phase field data as I stated, only the phi=0 contour, which is currently uploaded.

dschwen commented 6 years ago

I have already worked on a module to compute interface velocities during a simulation. In moose this could be combined with an extreme value postprocessor (assuming the dendrite tip is the fastest moving interface point) to get a pretty stable interface velocity. I can post more details tomorrow. It basically uses the Trevor's idea for time stepping that is also based on interface velocity (using the inverse gradient and the value change at each point).

wd15 commented 6 years ago

@dschwen, would that be something we can perform on the website with only the phi=0 contour at different time steps which is all we have.

dschwen commented 6 years ago

No, that would have to be done at simulation time. But it would not be terribly hard to implement in the various simulation packages.

stale[bot] commented 3 years ago

This issue has been automatically marked as stale because it has had no activity in the last year. It will be closed if no further activity occurs in the next 30 days. Thank you for your contributions.