mastmultiphysics / mast-multiphysics Goto Github PK

I've been testing MAST::POINT_MOMENT to test a spring-like element I'm implementing that behaves like Nastran's CBUSH element. I have a single bushing element (with stiffness in all six DOFs) aligned on the x-axis and the left end (at the origin) is fixed. Applying a moment about the x-axis, M_x, at the right end matches Nastran's results. It works with a moment about the y-axis, M_y, at the right end also. However, when I try a moment about the z-axis, M_z, at the right end it results in zero displacements.

The initial residual is also zero. I was trying to track down the issue and made it down to here. vec on line 209 is what I expect it to be, but the M_z value gets set to zero by line 220. If I change the logic from dof_indices[i] >= last_dof to dof_indices[i] > last_dof, then the value is no longer zeroed out and I get the expected displacement.

So, is the >= a bug or is there something else going on that I need to dive deeper into?

@jdeaton it appears that CI is building the docs, but failing to deploy it:
https://travis-ci.com/MASTmultiphysics/mast-multiphysics/jobs/275615995

Could you throw some light on the sequence in which MAST::NonlinearImplicitAssembly::PostAssemblyOperation::post_assembly() is called with respect to MAST::SecondOrderNewmarkTransientSolver::solve()?

OS: Ubuntu 16.04
Compiler: GCC 5.4.0 (OpenMPI version 3.0.1)
Boost Version: 1.61

Compiling MAST fails at 99% on both the check_fluid_jacobian.cpp and check_fluid_eigenvector.cpp files. In particular, it fails on this line with the message

MAST_INSTALL/external_programs/MAST/tests/fluid/jacobians/check_fluid_eigenvectors.cpp:61:47: error: expected constructor, destructor, or type conversion before ‘;’ token
BOOST_TEST_GLOBAL_FIXTURE( GlobalTestFixture );
^

If I comment out lines 60-64 in both files the build completes. However, as expected, this causes both tests (1/2 and 2/2) to fail when running make test.

Edit: Fixed quote block.

As mentioned in #57, it seems that the load is not being captured during the residual evaluation in structural example 2. This may be due to some of our recent changes, or perhaps there is a command line option that I am not aware of.

@manavbhatia Here, should libmesh_assert(!_initialized); actually be libmesh_assert(_initialized);?

The unique_ptr should already be pointing to null before initialization and logically you would only need to clear your property card, after it has been initialized, not before. If I'm missing something, could you explain what it is?

It seems that the bending about the y-axis is incorrect. It appears to be using the using the I for bending about the z-axis instead of the I for bending about the y-axis.

I believe the problem is is located here and here, and the indices need to be changed from (0,1) to (1,1) and from (0,5) to (1,5) respectively. I tested this change and it seemed to work on my end.

If you agree this is the appropriate fix, I can create a pull request for the fix.

Reviewing the stiffness matrix for Timoshenko beam's in Cook's finite element textbook (4th edition), when kappa-->inf (or k=1/kappa=0 in the Cook textbook), the bending stiffness matrix reduces to that of Euler-Bernoulli beam theory.

I tried this in MAST, using MAST::BERNOULLI for Euler-Bernoulli theory and using MAST::TIMOSHENKO and kappa=4.503e+15 to simulate Euler-Bernoulli theory with a Timoshenko formulation.

However, when I do this, the Jacobians between the two formulations do not match. I end up with some very large values on the diagonal for the Timoshenko case. Alternatively, I checked the case where kappa=0, and I get some zero's on the diagonal.

Could you shed any light on why Jacobian_bernoulli does not equal Jacobian_timoshenko as kappa-->inf?

It seems that the stiffness matrix for 1D structural elements is becoming indefinite in some cases. Similar to the issue we saw with the 1D mass matrix.

The specific case I found is a 1D elment with Euler-Bernoulli bending and the shear coefficient kappa set to zero to disable transverse shear stiffness. So this element should only have extension stiffness, bending stiffness, and coupled extension-bending stiffness. Some test results are below:

I'm still trying to track the issue down.

Edit: Remove an incorrect statement.

Documentation is successfully getting built, but for some reason is not deploying to website after recent changes. I'll try to get to this in the next couple of days.

https://travis-ci.com/MASTmultiphysics/mast-multiphysics/jobs/263580264

I'm been implementing some tests in MAST using Catch2. I've noticed in the 1D and 2D section property cards that the section stiffness properties require a MAST::ElementBase reference as an input parameter, however they are never actually used anywhere in the calculations. From a testing standpoint, this would require the creation of a MAST::ElementBase object which, I believe, would also require the creation of MAST::SystemInitialization, MAST::AssemblyBase, and MAST::GeomElem objects as well in order to test a "section" card.

To get around this in the 2D element, I overloaded those methods (e.g. stiffness_A_matrix, stiffness_B_matrix, etc.) where the overloaded method does not require any input parameters. This removes the need to create those other MAST objects which aren't actually used and simplifies the test. Intuitively, I think this make a bit more sense as well since an element depends on a section, but a section shouldn't depend on an element.

Before, I do the same for 1D elements. I wanted to get thoughts on this. Is there a particular reason these sections are set up to require an MAST::ElementBase input parameter when its not used? Is there any obvious disadvantages to me creating these overloaded methods for testing purposes?

@jdeaton Structural example 1 currently is setup for a 1D bar analysis. I think you intended for this to be a simple introduction for users.

Would it make sense to make this beam bending analysis (perhaps with nonlinearity turned on) and also demonstrate modal analysis and sensitivity analysis in the same example?

The issue is that 1D structural elements do not seem to be constructed properly when they not aligned with the x-axis. For example, the 1D bar extension example works fine when it is oriented along the x-axis with force acting in x-direction, but if I try to solve the same problem with the bar oriented along the y-axis instead with force acting in y-direction, it no longer solves.

I've attached a simple source file that demonstrates this.

I came about this issue when trying to solve the 10 bar truss problem, imported into MAST from an input file. In that case, I narrowed it down to the weighted Jacobian, from get_JxW(), is becoming NaN in some cases which results in NaNs in the residual and the program terminates, with a zero solution and no error code. I tried input files for the 3 bar truss and a vertically oriented 1 bar extension case, and saw the same behavior.

I tried an unmodified (i.e. from GitHub) version of MAST with the example file (attached) to rule out an issue with my input file reader or my modified MAST code. I didn't examine the weighted Jacobian for the example attached (I didn't modify the MAST source to print out this value), but I suspect the same issue is occurring here.

Although untested, I feel like this issue could spill over into other structural models with 2D and 3D elements, that utilize 1D elements as well.
bar_extension_vertical_pointload.zip

Edit 1: Fixed typo

As I've been working the last few days I've been using clang-tidy and checking out some of the warnings/errors it gives to see where we can clean things up.

It turns out that an underscore followed by a capital letter is a reserved name in C++ in any scope according to the C++ standard. Incidentally, we use this quite a bit throughout MAST due to the use of an underscore in front of a lot of private/protected member names. For example, _A and _Kappa technically are bad. I like delineating the private members with something, but maybe when we define a style guide we can address this in a future release. We obviously haven't hit any issues, but would probably be good to change anyways at some point.

An underscore followed by a lower case letter is a reserved name at file-level/global scope. I don't believe we have an issue with this anywhere.

• https://en.cppreference.com/w/cpp/keyword
• https://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier

One thing that would make the generated API documentation more readable is to move the "Detailed Description" to the top of the page. This can be done by providing a layout file (https://stackoverflow.com/questions/19831837/documenting-with-doxygen-put-details-on-top).

It would also be useful to provide some consistent guidelines for documenting all classes and work towards them.

• http://www.doxygen.nl/manual/docblocks.html

This issue is a placeholder for my notes & work in progress for defining a style guide for our custom CMake modules and CMakeLists.txt files.

Some references:

• http://nupic.docs.numenta.org/1.0.2/contributing/cmake-style-guide.html
• http://docs.ros.org/jade/api/catkin/html/user_guide/standards.html
• https://community.kde.org/Policies/CMake_Coding_Style
• https://cmake.org/cmake/help/v3.13/manual/cmake-developer.7.html
• https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1
• https://github.com/richq/cmake-lint
• https://llvm.org/docs/CMakePrimer.html
• https://github.com/onqtam/awesome-cmake

What is the purpose of the loop here?

This issue is for discussion of how to organize the example programs for the MAST library. We have previously decided that each example program meant for users to use to learn with should be stand-alone (something like the example_driver or more build-up programs might be good for tests). We also decided that we like the highly commented tutorial examples in the deal-ii library.

Since there are already a lot of examples I propose that we get as many of them as we can organized as independent programs and broken out of the example_driver. In doing this, we might also want to consider how to use them appropriately with an automated testing framework.

In parallel to this, we should start a series of "tutorial" examples that are heavily commented like deal-ii. These should start with a simple example, and progressively add more complexity/capability to it with later steps. I think we can use either CMake or doxygen to create the HTML pages like is done in deal-ii for the tutorial portions.

To me this implies a directory structure for the time being as something like:

• examples/tutorial/step-1
• examples/tutorial/step-2
• examples/tutorial/step-n
• examples/fluid/*
• examples/fsi/*
• examples/structural/*
• examples/thermal/*

While getting the CI system to check that examples will execute (PR #57) I came across some issues in the implementation of the examples with optimization. It seems that there are 2 main issues we need to revisit:

1. Conditional compilation with SNOPT/GCMMA/etc. optimizers is not working as expected when it comes to the examples. It seems we need some extra pre-processor guards in the examples' source to handle cases where there is one optimizer available, but not all of them. Right now it seems that the structural topology optimization examples will only successfully link when both GCMMA and SNOPT are available and support built for them in the MAST library.

2. Expand example demos to use NLOPT (or other open-source) optimizer. It seems we might have started to do this, but did not complete it. This will enable us to potentially check these examples execution on CI as well as provide an alternative to licensed (SNOPT) or special distribution (GCMMA) optimizers.

Greetings,

It seems that if I set -DENABLE_NLOPT=ON (one of the CMAKE List variables to enable compiling examples 5, 6, and 8) the compiler complains it can't find the interfaces for the SNOPT and GCMMA libraries when compiling the cpp files for these examples. It looks like the include files for those interfaces are only provided if -DENABLE_SNOPT=ON and -DENABLE_GCMMA=ON (In which case both libraries must be provided for the CMake configure). I'm not sure if there's a workaround I'm missing to make the examples work, thanks for any help rendered in advance.

@jdeaton : A new README.md file was added in the doc/ subdirectory in #12 . It is showing up as an extra page in the documentation, which I am not sure is needed.

Unless there is a specific need/intent for it, can we remove it?

While configuring GitHub Actions in this repository and attempting to get MAST to compile with both libMesh versions 1.5.1 and 1.6.2 I ran into issues related to handling of the timpi libraries. libMesh version 1.5.1 does not appear utilize timpi directly, whereas it is required for version 1.6.2.

It appears there is a workaround in the cmake/FindlibMesh.cmake file to assign the libMesh libraries to the timpi variables if timpi isn't found (as in the case of v1.5.1). I believe we can handle this better by detecting if libMesh version is >=1.6.0 and make them required.

It appears that compliance_output does not consider point loads when it is being evaluated here.

I tested it on 2D representation of a cantilever beam, bending in-plane, both with 1 element and 4 elements in the mesh. For both cases, the vec vector remains entirely zero after e.side_external_residual and e.volume_external_residual have been called.

I only started diving into the "output" type source code today, but to me it looks like we'll need a way to determining which node(s) that point load is acting and which element(s) belong to that node. Thenm apply it in a way that the point load doesn't get redundantly included if it acts on a node that is shared by multiple elements.

Do you have any suggestions/thoughts on whats the best/easiest way to include point loads in the compliance output?

Josh and I have discussed this a few times. It seems like the shear correction factor (kappa) might be better suited as a section property as opposed to a material property.

According to this, it looks like kappa is a function of both the geometry and Poisson's ratio. However, most FEA programs treat it as a section property. For MAST to be a little more intuitive for both users and developers (and to help reduce the learning curve for potential future users), it may be worthwhile to move kappa from a material property to a section property card.

We'd like to get your thoughts on this.

I actually just discovered the bending_operator stuff last week. But when I tried using it and set NO_BENDING in a 1D extension example problem, I get an error indicating "property not found for : kappa". Looking at the stack trace, it looks like the TimoshenkoBendingOperator is calling the calculate_transverse_shear_residual. It seems odd that NO_BENDING is resulting in the TimoshenkoBendingOperator being called, but I haven't look through the code to see how you implemented it yet.

Originally posted by @JohnDN90 in #40 (comment)

This issue is for discussion related to getting Travis CI working in the main repository.

Once setup properly Travis CI can be used to test builds on both Linux and MacOS as well as to automatically run tests. I believe it could also be used to run doxygen and automatically keep the documentation on the website up to date with the master branch.

My fork currently has a travis-ci branch that has somewhat diverged from the one currently in this repository while I am experimenting. The .travis.yml there is currently running a build in their default containerized environment on Ubuntu 14. The containers have the equivalent of 2 cores. I've found there is a 50 minute limit on jobs.

Currently, I'm using Spack to install dependencies, which takes longer than 50 minutes with those resources, so the build is timing out and being killed. There is functionality to cache the build process, which I have turned on. The build should be caching on failures (travis-ci/travis-ci#9224), but I'm not seeing that happen so far. Still need to play around some more later. If it does cache properly, Spack should be able to pick-up which parts of its chain were successfully installed on a previous run.

I've sent Travis support an email to see if we can't get a temporary job limit increase to get through the dependency builds as an easier solution.

I think the alternative solution will be to use the native package manager (and maybe Homebrew on MacOS when I get to that point) to install dependencies like cmake/openmpi and setup a manual build script for PETSc/SLEPc/libMesh/etc. This should hopefully get things down under the 50 minute limit to get a full cache of the dependencies.

@manavbhatia One thing @JohnDN90 and I noticed was that there is a mix of protected and public residual/Jacobian methods in the elements. The protected ones (for example thermal_residual() in 1D structural elements) are called from within larger public residual methods. We found that this complicates testing these calculations in isolation (from the larger encompassing residual method) in our Catch2 test setup.

One current work-around we are using is adding #define protected public before including the relevant headers, but this seems to be a bit of a cludge and makes basically EVERYTHING public. Although I have found a lot of discussion in various C++ forums where it is common to use that along with #define private public.

In the interest of increasing testability, what do you think of making all residual calculation methods public in the elements?

Similar to the code here, does following code correctly setup the discipline for accepting point loads from the FSI module?

MAST::PointLoadCondition fluid_load(MAST::POINT_LOAD);
libMesh::MeshBase::node_iterator niter   = mesh.nodes_begin();
libMesh::MeshBase::node_iterator niterend  = mesh.nodes_end();
for ( ; niter != niterend; ++niter) {
  fluid_load.add_node(**niter);
}
discipline.add_volume_load(0, fluid_load);

Further, how do I pass the actual load values to the solver in the time stepping loop?

I am trying to use tied constraints and sensitivities for a design optimization problem we are facing. I am running structural_example_4 as an example for how to accomplish this. However, when I run this example, the resulting mesh reports zero stresses across the entire domain.

I am running the following:
./structural_example_4 -ksp_type preonly -pc_type lu

The fields structural_u and structural_t are populated. My first guess is that displacement is being reported as zero and the resulting stress is thusly zero.

Any ideas on how to remedy this issue? Am I running this example correctly?

ThermalJacobianScaling::set_assembly() requires argument of type MAST::NonlinearImplicitAssembly. Could it be modified to also accept MAST::TransientAssembly?

In order for my MAST spack package to work as designed and be pulled into the mainline spack repository, we need to define version numbering for MAST. I think now is also a good time to try to migrate some of the recent work back into this repository and come up with a branching/pulling strategy to incorporate stabile capabilities into releases.

As far as I can tell from reading around, a good version strategy is A.B.C where A involves major API breaking changes, B adds functionality, and C are hotfixes. Perhaps a good 0.X.0 (start X at whatever number you want) release would be to incorporate the refactored CMake build system with 3 simple examples (same problem, first do analysis, then do direct sensitivities, then adjoint sensitivities). For the 0.(X+1).0 release we can simply add more examples.

I did some searching and it seems like there are various strategies for using branches to collect commits/features into releases and manage incorporating bug-fixes.

• GitHub Flow: https://guides.github.com/introduction/flow/
• Git-flow: https://datasift.github.io/gitflow/IntroducingGitFlow.html, https://nvie.com/posts/a-successful-git-branching-model/
• Forking Workflow: https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow (based on Git-flow with GitHub forks)
• Forking Workflow (without develop branch): https://hackernoon.com/a-branching-and-releasing-strategy-that-fits-github-flow-be1b6c48eca2

I think one of the last two looks like it might work best.

@JohnDN90 are you using the PointLoadSetType for any of your work? I am looking to add a more general point load data structure and can keep or remove this based on current utility.