-
Notifications
You must be signed in to change notification settings - Fork 83
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
Add math function from file #692 #701
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks okay to me, @ezrayst, one minor comment only. A small question: could you let me know which lines assign these math_functions to nodal variables acceleration/velocity/displacement? Or is it coming in the near future? Thanks btw!
Codecov Report
@@ Coverage Diff @@
## develop #701 +/- ##
============================================
+ Coverage 83.91% 96.73% +12.82%
============================================
Files 169 130 -39
Lines 34176 25849 -8327
============================================
- Hits 28676 25004 -3672
+ Misses 5500 845 -4655 Continue to review full report at Codecov.
|
It should be coming next, but it is briefly described here #692, @bodhinandach |
@ezrayst are acceleration time histories typically only 1d? |
@jgiven100, in 2D we usually only use the horizontal acceleration (not vertical), so earthquake input will only be in one direction. In 3D, we have two lateral directions. But maybe that is not your question (I might be reading too much into this). If we need to run horizontal and vertical acceleration time history, we will have math_function_0 for the x axis and math_function_1 for the y axis. |
@ezrayst Right, I was thinking about the 3D case. Seperate math functions for the 2 directions understood 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of writing a custom csv reader, it would be better to use https://github.com/ben-strasser/fast-cpp-csv-parser
Also, the input JSON file structure is needed. Please add more details to the PR describing the design and input file structure.
Hi @kks32, two things:
|
No
|
@kks32 I updated the initial comment, and I will change to CSV within today, hopefully. Thanks! |
@kks32, please let me know if you would like to discuss the structure of the code, but currently I have changed to csv file input. I think I see you are concerned about the size of the file - but I think typical earthquake ground motion would be in the order of thousands of entries, not millions. Thanks anyways! |
Hi @kks32, do you still have more comments? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
create a folder inside external for csv
and then add their license as well. Follow the convention.
include/solvers/mpm_base.h
Outdated
@@ -27,6 +27,9 @@ | |||
#include "particle.h" | |||
#include "vector.h" | |||
|
|||
// CSV-parser | |||
#include "csv.h" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be included in io
class not mpm base
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we move json
and catch
to their own respective folders?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please add a test that shows you can read the files and get the correct x and fx values?
@@ -762,16 +762,44 @@ bool mpm::MPMBase<Tdim>::initialise_math_functions(const Json& math_functions) { | |||
const std::string function_type = | |||
function_props["type"].template get<std::string>(); | |||
|
|||
// Initiate another function_prop to be passed | |||
auto function_props_update = function_props; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need this?
io_->json_object("mesh")["io_type"].template get<std::string>(); | ||
auto reader = Factory<mpm::IOMesh<Tdim>>::instance()->create(io_type); | ||
|
||
// Math function is specified in a file, replace function_props_update |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Read files in io
class not in mpm_base
. Create a separate class in io
or use the read_mesh_ascii
to read these files. I'd prefer for now if you use read_mesh_ascii
to read the input file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's what I have tried to use in the beginning, and you requested CSV. Can we agree on which one to use now before I make more changes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not asking you to revert back, this is an io
operation and reading the CSV should be in the io
class as an additional function and not in the mpm_base
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, so still CSV but within read_mesh_ascii
. But doesn't it refer to ascii
not csv
?
// Create a new function from JSON object | ||
auto function = | ||
Factory<mpm::FunctionBase, unsigned, const Json&>::instance()->create( | ||
function_type, std::move(function_id), function_props); | ||
function_type, std::move(function_id), function_props_update); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is it called function_props_update
?
// Math function is specified in a file, replace function_props_update | ||
if (function_props.find("file") != function_props.end()) { | ||
// Make separate arrays | ||
std::vector<double> xvalues; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having separate vectors makes it decoupled between x and y values, use a vector of arrays instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK
@ezrayst This PR is a generic PR for reading x and fx values from a CSV file and has nothing to do with acceleration time histories per se. Please update your PR details accordingly, you may see it will be used for acceleration time histories, but there is no need to discuss how it will be implemented at the node level because that's not done here. Provide details specific to this PR, which is missing (an input JSON file and an example CSV file would help). These are the core details and should be included rather than a link to mpm-doc PR. |
Hi @kks32. I will update the PR accordingly then, to just simply update the |
io_->json_object("mesh")["io_type"].template get<std::string>(); | ||
auto reader = Factory<mpm::IOMesh<Tdim>>::instance()->create(io_type); | ||
|
||
// Math function is specified in a file, replace function_props_update |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not asking you to revert back, this is an io
operation and reading the CSV should be in the io
class as an additional function and not in the mpm_base
#715 supersedes this PR. Closing |
Describe the PR
Math function is modified to read acceleration time history of an earthquake, thus better to have it from a file instead of simply a json entry.
Related Issues/PRs
Part 1 of #692
Explanation
This design utilizes the available class structures already available. It mirrors the velocity boundary condition, with input being
with the variation over time defined in the
math_function
. With that, the acceleration will be kept at1.0
innode
andmath_function
defines the ground motion. The advantage is the robustness as we now have acceleration boundary condition as input, and it can be modified easily to allow for dynamic inputs. This method is preferred, but there may be extra double at each constrained node.math_function
can be defined through a csv file as shown here: https://ezrayst.github.io/mpm-doc/#/user/preprocess/input?id=math-functionsAlternative
To have another class,
timehistory.h
to define acceleration and stress over time. Those can have public functions such asapply_acceleration_time()
that can be called in our solver (mpm
) and applied directly instead of having a static value innode
. This will mean that we have separate json entry calleddynamic_input
such as follow: