nrel / hydrochrono Goto Github PK

Hi

When will the "Get started" file be available, this program is very attractive to me and I would like to try to use it.

Best regards, You're doing a great thing.

• Make demos with floating bodies that have objects without hydro forces attached:
• large hull with flat deck, add waves, put demo_IRR_tracks from Project Chrono on top of the deck
• Demo with flexible body (maybe floating wind turbine demo)
• demo with moordyn when coupled
• Other similarly complex demos (extend list later)

Recently noticed that all the decay tests were off slightly and that this issue was on main. Here are some plots showing previously obtained results to the problematic plots generated recently:
For the sphere, notice the amplitude/frequency adjustments between previously correct data and new bad plot:

RM3 also shows this issue:


(note the simulation ran for a shorter amount of time in the recent plot, this is not relevant for the issue)

F3OF has similar results for the surge decay test and the pitch decay test (DT1 and DT2) but the flap pitch decay test is worth noting:

There are improvements that could be made on the Impulse Response Function (IRF) sampling/interpolation to make HydroChrono more flexible/robust in terms of time stepping.

The issue

In the current implementation, there are limitations regarding the time step to use in HydroChrono.
In terms of dt (time step) defined in the code, right now we have:

• Radiation IRF (RIRF) sampled at the dt used for the hydro database (.h5)
• Excitation force IRF sampled at a user defined dt
• Simulation (Chrono) dt

For things to work fully as intended, we need the simulation dt to be the same as the RIRF dt defined in the .h5 file, and we need the excitation force IRF sampling dt to be the same as the simulation dt.
In other words, the RIRF dt must be imposed everywhere with no resampling, and it has to be a fixed dt. Since the .h5 file is computed as a preprocessing step outside of HydroChrono, it means that we cannot set a different dt within HydroChrono.

The potential solution

To allow for a more flexible dt, we can either:

• Allow for resampling of the RIRF so we can at least choose a fixed dt within HydroChrono (this is already done for the excitation force IRF)
• Make sure that the calculations involving the IRFs use proper interpolation even when using a variable dt --> this is the safest and most flexible approach, at the expense of some extra calculations

Work towards a stable, verified, and documented 1.0 release for HydroChrono. Primary tasks include:

• Documentation:

  • convert existing comments to sphinx comment format,
  • document any undocumented functions/classes (sphinx style),
  • link tests/plots to sphinx generation, update readme.md with important info

• Verification:

  • verify results for decay tests,
  • verify regular wave tests,
  • verify irregular wave tests

• Ensure file names consistent:

  • plot files, output files, comparison data files, should all be named consistently (should be done, just need to double check this is true in all cases)

WEC-SimReference is not a reference in references.bib file

• check all member functions for naming convention: CapitalizeFirstLettersOnFunctions(). This includes at least:
  • HydroForces::coordinateFunc() rename to HydroForces::CoordinateFuncForBody() (add in slight name change to avoid confusion)
  • ForceFunc6d::coordinateFunc() rename to ForceFunc6d::CoordinateFunc()
  • H5FileInfo::readH5File() rename to H5FileInfo::ReadH5File()

jmse7030081 is not a reference in references.bib file

In situations where one body in the chrono system is fixed in place, Project Chrono removes its mass/inertia matrix from the system's mass/inertia matrix. This does not cause problems when applying forces to the fixed body, but does cause problems when the added mass matrix is larger than the system mass matrix.
There is a current (yet messy) solution: say the fixed body in the system is called body1. Then instead of fixing body1 in place, create a new extra ChBody called floor. Fix floor and link it to body1. Now, since body1 isn't fixed, its mass matrix is part of the system mass matrix and since floor is fixed, chrono removes its mass matrix from the system. Then added mass can be added as normal. This is the current method of fixing bodies in demo_oswec_decay and demo_f3of_DT3. See excerpt from oswec below:

   // define the base's initial conditions
    system.Add(base_body);
    base_body->SetPos(ChVector<>(0, 0, -10.9));
    base_body->SetMass(999);
    base_body->SetInertiaXX(ChVector<>(1, 1, 1));

    // create ground
    auto ground = chrono_types::make_shared<ChBody>();
    system.AddBody(ground);
    ground->SetPos(ChVector<>(0, 0, -10.9));
    ground->SetBodyFixed(true);
    ground->SetCollide(false);
    // fix base to ground with special constraint (don't use setfixed() because of mass matrix)
    auto anchor = chrono_types::make_shared<ChLinkMateGeneric>();
    anchor->Initialize(base_body, ground, false, base_body->GetVisualModelFrame(), base_body->GetVisualModelFrame());
    system.Add(anchor);
    anchor->SetConstrainedCoords(true, true, true, true, true, true);  // x, y, z, Rx, Ry, Rz

This issue can be resolved when the above code is replaced with

   // define the plate's initial conditions
    system.Add(base_body);
    base_body->SetNameString("body2");
    base_body->SetPos(ChVector<>(0, 0, -10.9));
    base_body->SetMass(999);
    base_body->SetInertiaXX(ChVector<>(1, 1, 1));
    base_body->SetBodyFixed(true);

and the demo runs, producing correct results.

Hi

I am trying to build HydroChrono, but meet errors as bellow:

the cmake gui shows I finished the make process:

Has anyone else had this problem?

Right now, hydro bodies have to be added to the chrono system before any other chrono body or node. This is because the (dense) added mass matrix of hydro bodies is assumed to be at the upper left of the (sparse) global mass matrix. For some applications, it would make it easier to be able add hydro bodies after other bodies.

This could probably be done by populating the global mass matrix with added mass terms using the actual indices of the hydro bodies assigned by the system.

Go through warnings from build step, and adjust code or ignore warnings to best fit each warning instance. For example, one warning is "'<': signed/unsigned mismatch" and can be solved by changing the types to either be both signed or both unsigned depending on context.

Hi

I am very interested in this project and I would like to try to use this program, can I get a guid on how to install and compile it？

Best regards

Currently, multibody demos for decay tests have lines like these in order to run without crashing:

    auto default_dont_add_waves = std::make_shared<NoWave>(3);

    // set up hydro forces
    std::vector<std::shared_ptr<ChBody>> bodies;
    bodies.push_back(base);
    bodies.push_back(flapFore);
    bodies.push_back(flapAft);
    TestHydro hydroforces(bodies, h5fname, default_dont_add_waves);

(From F3OF demo)
Where the default_dont_add_waves object is required to be passed. Ideally, this object should be omitted from the demo set up. If no wave object is given to hydroforces constructor, then the default should be a NoWave object with correct size for number of bodies.
In other words, the above code should be replaced with:

    // set up hydro forces
    std::vector<std::shared_ptr<ChBody>> bodies;
    bodies.push_back(base);
    bodies.push_back(flapFore);
    bodies.push_back(flapAft);
    TestHydro hydroforces(bodies, h5fname);

to have the same results. Note, this works for single body systems since the default is a NoWave(1) object.

Tasks for this issue:

• Default NoWave should account for multibody systems as described above
• Remove default_dont_add_waves objects from multibody decay demos to prove functionality, and increase readability

hydro_forces.cpp contains too many different classes and functions; needs to be refactored into multiple files e.g.:

• chrono-specific classes/functions (ForceFunc6d, ComponentFunc)
• wave classes/functions (regular/irregular, eta, surface mesh etc)
• hydrodynamics (radiation/excitation convolution integral)

• For all mathematical vectors, arrays, matrices, and other multidimensional data we need to switch to the corresponding Eigen::VectorXd, Eigen::MatrixXd, Eigen::Vector3d, or similar object (depending on situation).
• This applies to all multidimensional data that mathematical operations need to be performed on, and does not apply to lists of things. For now, continue using std::vector<> as a way to manage a dynamic sized list of objects. For example, the std::vector<chrono::ChBody> vector initialized in main should continue using an std::vector<>. Similarly, the velocity history vector which keeps track of the 6-dimensional velocity of the body at timestep t should continue using std::vector<Eigen::VectorXd> (where the size of X in the Eigen type vector is 6 and the std::vector index keeps track of the timestep t).
• Note, Project Chrono has typedefs for many of the Eigen types. For consistency in this project use the bare Eigen type names instead of the typedefs included from Project Chrono when possible. For example, Eigen::MatrixXd should be used in place of chrono::ChMatrix (even though they are the same in the end).
• Primarily, the reason for this change is efficiency. Eigen has many built in functions for mathematical operations on vectors and matrices that are incredibly efficient.