idaholab / malamute Goto Github PK
View Code? Open in Web Editor NEWAdvanced manufacturing modeling and simulation
Home Page: https://mooseframework.inl.gov/malamute
License: GNU Lesser General Public License v2.1
Advanced manufacturing modeling and simulation
Home Page: https://mooseframework.inl.gov/malamute
License: GNU Lesser General Public License v2.1
In GitLab by @cticenhour on Dec 14, 2021, 17:21
Merges integrate-freya -> devel
This MR adds code formerly residing in Freya to MALAMUTE. The MALAMUTE Makefile and documentation configuration were also updated to accommodate the new code and new module dependencies. Issues relevant to the history retained by moving over Freya objects, tests, and input files have been re-created in MALAMUTE for SQA reference and compliance.
Closes #5
Closes #9
Closes #10
Closes #11
Closes #12
Closes #13
Refs #14
Closes #15
Closes #16
Closes #17
Closes #19
Refs #20
Closes #21
Closes #22
Closes #23
Closes #24
Closes #25
Closes #26
Refs #29
Closes #31
Closes #32
In GitLab by @cticenhour on Dec 14, 2021, 15:39
This issue is a reproduction of the archived freya#5 for SQA purposes. Please refer to that issue for any extended discussion that may exist beyond this description.
In order to fully duplicate the results in the Cincotti paper validation, a radiative heat flux boundary condition is needed. This is general enough that it could be added to the MOOSE heat conduction module. For expediency, though, putting it in Freya for now is ideal.
The condition outlined in Cincotti et al, Figure 4 needs to be implemented.
New capability.
In GitLab by @cticenhour on Dec 14, 2021, 16:14
This issue is a brief summary of discussion results in freya!46 for SQA purposes. Please refer to that merge request for any extended discussion that may exist beyond this description.
The two way coupling input files added in freya!46 are untested.
Add RunApp
tests for the two way coupling input files using lots of particles.
Better coverage.
In GitLab by @sapitts on Aug 4, 2022, 13:18
Merges convert_shellscript_to_test_33 -> devel
Consolidates the single square block inputs into a single file for yttria and a second single file for graphite. Several of the input files in this folder were small variations on the electro-thermal-mechanical problem for yttria which did not require separate input files.
The shell script originally included in this directory was used only to generate a demonstrative plot for the LDRD poster. The temperature variations in the shell script and plotting capability are not needed to help advance the research in this area.
Closes #33
In GitLab by @cticenhour on Dec 14, 2021, 15:43
This issue is a reproduction of the archived freya#7 for SQA purposes. Please refer to that issue for any extended discussion that may exist beyond this description.
Cincotti et al (2007) AIChE Journal vol53 no 3 uses thermal and electric conductances that depend on applied mechanical load and temperature (Equations 8 - 12). These equations should be added as functions (requesting values from the materials in freya#6) so that they can be applied to the interface kernels for thermal and electric contact.
Add thermal and electric conductance functions that depend on temperature and mechanical load (the latter defined by the user as a constant value). Harmonic means of thermal and electric conductivity as well as hardness for the two materials in contact need to be evaluated by this object. Interface conditions also need to be modified to accept functions for the transfer coefficient.
Improves solutions for Cincotti validation effort, and adds infrastructure needed for future cases with plunger and die assembly.
In GitLab by @cticenhour on Dec 14, 2021, 16:01
This issue is a reproduction of the archived freya#21 for SQA purposes. Please refer to that issue for any extended discussion that may exist beyond this description.
Validation comparisons of the Freya code require geometry and input files that align with the specifics of the CAES Dr. Sinter machine.
Add mesh script, mesh, and corresponding input files
Will add capability to run engineering scale simulations for direct comparison with the CAES Dr. Sinter machine
In GitLab by @cticenhour on Dec 23, 2021, 22:50
Merges fixup-doco-27 -> devel
The root of the documentation failure is a tensor mechanics module design spec added in idaholab/moose#18721. The fix is to make sure ${MOOSE_DIR}/modules/doc/content/help/finite_element_concepts/nodal_patch_recovery.md
is included in the MooseDocs config file for MALAMUTE. ${MOOSE_DIR}/modules/doc/content
couldn't be added by itself, because that requires links to other modules that MALAMUTE doesn't currently depend on.
The implementation of this fix was taken from idaholab/blackbear#286
This MR also adds a link to the code coverage on the MALAMUTE website navigation.
Closes #27
Refs #28
In GitLab by @cticenhour on Dec 14, 2021, 15:47
As material properties become non-linear, MALAMUTE needs to use AD to make development easier. Making this issue as a catch-all for this effort.
InterfaceKernels --> ADInterfaceKernels
Materials --> ADMaterials
And <is_ad>
templating as needed if dual versions are desired.
No change to external APIs, but more flexibility and ease of development.
In GitLab by @cticenhour on Jul 13, 2022, 09:05
As part of !5, a script for temperature dependent runs is being checked in at
examples/sps/multiapp/diemodel/electrothermomechs/simple_geometries/run_isoPlastic_all_temperature.sh
This should more likely be a set of tests, or some other method that allows us not to have to check in a random script and keeps the capability tested.
See above
Removes extraneous files from MALAMUTE and enhances testing
In GitLab by @cticenhour on Dec 14, 2021, 15:54
This issue is a reproduction of the archived freya#13 for SQA purposes. Please refer to that issue for any extended discussion that may exist beyond this description.
Freya is breaking tests due to recent ELK update, which updated the ElectrostaticContactCondition object.
Run tests with current devel and see failures.
Prevents Freya from updating, should be fixed ASAP.
In GitLab by @cticenhour on Dec 14, 2021, 16:08
This issue is a reproduction of the archived freya#28 for SQA purposes. Please refer to that issue for any extended discussion that may exist beyond this description.
Freya docs are broken due to a duplicate image conflict resulting from the development of the electromagnetics module:
RENDER ERROR: Multiple pages with a name that ends with 'two_block.png' were found:
media/two_block.png
large_media/electromagnetics/two_block.png
/opt/civet/build_1/freya/doc/content/verification/thermal_contact_verification.md:339
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
339│ │
340│ │
└───────────────────────────────────────────────────────────────────────────────────────────────┘
Traceback (most recent call last):
File "/opt/civet/build_1/freya/moose/python/MooseDocs/base/renderers.py", line 77, in render
el = func(parent, token, page) if func else parent
File "/opt/civet/build_1/freya/moose/python/MooseDocs/extensions/media.py", line 151, in createMaterialize
tag = self.createHTML(parent, token, page)
File "/opt/civet/build_1/freya/moose/python/MooseDocs/extensions/media.py", line 141, in createHTML
node = self.translator.findPage(src)
File "/opt/civet/build_1/freya/moose/python/MooseDocs/base/Translator.py", line 223, in findPage
raise exceptions.MooseDocsException(msg)
MooseDocs.common.exceptions.MooseDocsException: Multiple pages with a name that ends with 'two_block.png' were found:
media/two_block.png
large_media/electromagnetics/two_block.png
Try to build Freya docs with current MOOSE submodule.
Docs will not build correctly until fixed.
In GitLab by @loganharbour on Oct 25, 2021, 18:28
A coverage configuration allows the coverage requirements to be changed on a per-commit basis and introduces transparency on these requirements.
Add a .coverage
file.
More transparency for coverage requirements and ease in changing the requirements.
In GitLab by @cticenhour on Aug 1, 2022, 10:49
coord_type
in Problem block is deprecated, so it should be moved to the Mesh block. See https://moosebuild.hpc.inl.gov/job/492755/
./run_tests -j8 --error-deprecated
Annoyance, but should be fixed before deprecation warning becomes full error.
In GitLab by @cticenhour on Dec 14, 2021, 16:06
This issue is a reproduction of the archived freya#24 for SQA purposes. Please refer to that issue for any extended discussion that may exist beyond this description.
We need an example input file using a plasticity material model that will be similar to the plasticity model developed from the mesoscale simulations.
Use the plasticity capabilities within tensor mechanics.
New capability.
In GitLab by @cticenhour on Aug 31, 2021, 19:06
MALAMUTE is not yet initialized as an INL MOOSE-based application.
The following needs to be performed to close this issue:
The beginning of MALAMUTE! The creation of this issue also serves as the beginning of issue tracking and eventual INL SQA compliance.
In GitLab by @cticenhour on Dec 23, 2021, 14:50
Merges integrate-baldr -> devel
This MR adds code formerly residing in Baldr to MALAMUTE. The MALAMUTE Makefile was also updated to accommodate the new code and new module dependencies.
Note: Baldr tests fail with the current MOOSE submodule version, so they are skipped for now until they can be fixed. This requires a drop in the minimum coverage until they are fixed up.
Refs #5
In GitLab by @cticenhour on Dec 14, 2021, 15:41
This issue is a reproduction of the archived freya#6 for SQA purposes. Please refer to that issue for any extended discussion that may exist beyond this description.
Cincotti et al (2007) AIChE Journal vol53 no 3 includes thermophysical properties as a function of temperature: heat capacity, thermal condutivity, electrical resistivity, and coefficient of thermal expansion. These figures (7 and 8) should be digitized and added to Freya for enable verification of the engineering scale model against this paper.
Add separate thermal, electrical, and mechanical property classes which depend on temperature
Easy of verification effort reproducibility
In GitLab by @cticenhour on Dec 14, 2021, 16:04
This issue is a reproduction of the archived freya#22 for SQA purposes. Please refer to that issue for any extended discussion that may exist beyond this description.
Validation comparisons against CAES Dr. Sinter machine experiments require data in a usable form for comparison with Freya models (and usage in models, in the case of voltage/current sources).
Add python script that can take as input .CSV output files from the Dr. Sinter experiments and processes them into .CSV files adequate for comparison and usage in Freya simulations. Also add plotting capability for viewing of processed data over time.
Enables validation simulation comparisons with experimental data.
In GitLab by @cticenhour on Dec 14, 2021, 16:21
This issue is a brief summary of discussion results in freya!36 for SQA purposes. Please refer to that merge request for any extended discussion that may exist beyond this description.
Electro-thermal-mechanical input file is broken and should be removed, the nodalcontact test is missing a mesh file, and the goofycontact input should be tested.
Remove electrothermomechanical input file, fixup electrothermal nodalcontact test, add electrothermal goofycontact test.
Better coverage, removal of un-needed inputs, and fixed up broken tests.
In GitLab by @cticenhour on Dec 14, 2021, 15:37
This issue is a reproduction of the archived freya#4 for SQA purposes. Please refer to that issue for any extended discussion that may exist beyond this description.
In order to realistically model SPS assemblies, both thermal and electrical conductance need to be properly handled at material interfaces.
An electrical conductance condition already exists within ELK (ElectricalContactResistance
), so a thermal conductance condition is needed. This is described in detail in Cincotti et al, Figure 4. A new InterfaceKernel
for dissimilar materials would need to be made to duplicate the condition outlined there.
New capability.
In GitLab by @cticenhour on Oct 6, 2021, 10:46
See idaholab/valhalla#2 for original issue. Description repeated below.
MALAMUTE needs to solve energy conservation equation of melt pool.
Create:
Add new features.
In GitLab by @cticenhour on Dec 23, 2021, 20:09
Main documentation is currently failing after the merge of !6, as a document needed for SQA was not found. See https://moosebuild.hpc.inl.gov/job/399397/
Checkout 9005062, build MOOSE and MALAMUTE, and run
cd doc
./moosedocs.py build --with-sqa
MALAMUTE SQA documentation does not properly build.
In GitLab by @cticenhour on Oct 12, 2021, 11:27
Currently, placeholders are in place for examples/demonstration problems and the getting started page. These need to be added so that new users can better navigate the capability available to them.
doc/content/demonstration/Placeholder.md
with summary documents for the current MALAMUTE examples.doc/content/getting_started/Placeholder.md
with getting started instructionsMake MALAMUTE easier to use for new users
In GitLab by @jiangwen84 on Oct 18, 2022, 14:39
We need to add a new kernel to move the level set according to the velocity due to powder addition.
New kernel will be implemented.
New feature.
In GitLab by @cticenhour on Oct 6, 2021, 11:40
See idaholab/valhalla#6 for original issue. Description repeated below.
Max time parameter is violated on test melt_pool_fluid.fluid
on CIVET
Inconsistent - seen mainly on CIVET for around the last month (February 2021) or so: https://moosebuild.hpc.inl.gov/job/309917/
Submodule updates not being merged to master.
In GitLab by @cticenhour on Dec 14, 2021, 15:50
This issue is a reproduction of the archived freya#11 for SQA purposes. Please refer to that issue for any extended discussion that may exist beyond this description.
Prompted by recent MOOSE and societal discussions, it's more important than ever to address old patterns and conventions of our work and make changes that get us to a point of technical clarity while also achieving inclusion for those who develop on our code base. "master/slave" naming conventions for objects and member variables is something that must be addressed.
Removal of "master" and "slave" in all Freya objects, if used, and replacement with something like "primary" and "secondary". "neighbor" seems to be the currently used paired name in Freya to "master", and this may be better suited to becoming "secondary" if "primary" is chosen. A change to "neighbor" is therefore somewhat optional.
No functionality change...only changes to documentation, parameter names, and class member names.
In GitLab by @cticenhour on Feb 22, 2022, 11:37
"New moosebuild" will break tests on CIVET due to OS, gcc, and mpich changes. Any failing tests should be fixed up before that changeover finishes.
The current failing tests are exodiffs:
test:melt_pool_fluid.fluid
test:gradient_regularization.gradient_regularization
New formerly freya tests being added in !5 had one failure due to a convergence issue:
test:bcs/radiation_heat_loss.simple_radiation
Open a terminal and perform the following:
% ssh rod.hpc.inl.gov
% new_moosebuild
% module load moose-libmesh-vtk python
% <clone current malamute>
% <build malamute>
% ./run_tests -j8
MALAMUTE will stop updating if this isn't fixed.
In GitLab by @cticenhour on Jun 30, 2022, 14:39
This is a adjusted reproduction of idaholab/freya#30 for SQA purposes
MALAMUTE fails to build in its current state if the changes related to the electromagnetics module are merged. See https://civet.inl.gov/job/1050922/ and idaholab/moose#17641
Set MOOSE submodule to the cticenhour/electromagnetics
branch in the PR linked above, and attempt to build MALAMUTE.
MALAMUTE will be nonfunctional when this change occurs unless it is patched.
In GitLab by @socratesgorilla on Dec 1, 2022, 12:58
Due to issues in MOOSE, unused parameters were not correctly erroring. The problem is being addressed in a PR here: idaholab/moose#22840
However, Malamute has accumulated unused parameters that should be replaced.
In GitLab by @cticenhour on Apr 21, 2022, 14:59
Merges fix-30-part-2 -> devel
Refs #30. This PR is a replacement for !8, which was forcefully reverted to clean up a commit history mistake.
In GitLab by @cticenhour on Oct 6, 2021, 10:47
See idaholab/valhalla#3 for original issue. Description repeated below.
MALAMUTE needs to solve momentum equations of melt pool.
Add new features.
In GitLab by @cticenhour on Jun 30, 2022, 14:37
This is a reproduction of idaholab/freya#31 for MALAMUTE SQA purposes
Due to new changes in the way moose handles default behavior for unused parameters, multiple freya tests are now hitting errors for their unused parameters
The specific input files are viewable in the attached MR, and can be seen on the civet job here: https://civet.inl.gov/job/1077110/
The Moose update will not be mergeable until this change is made, so it is of a high importance.
In GitLab by @cticenhour on Dec 14, 2021, 15:56
This issue is a reproduction of the archived freya#18 for SQA purposes. Please refer to that issue for any extended discussion that may exist beyond this description.
In the current version of cincotti_validation_interfacekernels_version.jou
, we set some sidesets within if statements corresponding to the sample number being meshed. As an example, see the relevant code here (L106 - L109) for sample three. These example lines contain only vertical externally-facing surfaces, and they are missing externally-facing horizontal surfaces within the graphite region. This leads to a no-flux condition being defined on those missing surfaces in Freya, rather than the preferred radiation condition.
Examine the sideset output of this file in cubit while setting model_sample_type
to 3 or 4.
Causes temperature discrepancies in solutions when comparing interface-biased cases using this file with non-biased meshes created previously.
In GitLab by @cticenhour on Dec 14, 2021, 15:57
This issue is a reproduction of the archived freya#19 for SQA purposes. Please refer to that issue for any extended discussion that may exist beyond this description.
Capture the MOOSE-based work that Al completed to generate a power law type constitutive model for the yttria powder mechanics
Include the input files, meshes, plotting scripts, and key results from the two and four particle contact models
Maintain accessibility of Al's work as he transitions to a new position
In GitLab by @cticenhour on Apr 21, 2022, 12:31
CIVET is breaking on the scheduled deprecated target (https://moosebuild.hpc.inl.gov/job/443495/), as well as the documentation target on main (https://moosebuild.hpc.inl.gov/job/443393/).
./run_tests --error-deprecated
).cd doc; ./moosedocs.py build
)High - documentation is not being updated on the website.
Deprecated code is a low impact currently, but needs to be fixed.
In GitLab by @cticenhour on Dec 14, 2021, 16:07
This issue is a reproduction of the archived freya#27 for SQA purposes. Please refer to that issue for any extended discussion that may exist beyond this description.
Deprecated code test failure on SideFluxIntegral
object. See https://moosebuild.hpc.inl.gov/job/360243/
Replace the object in input files with the identified replacement.
Removes usage of deprecated MOOSE objects.
In GitLab by @cticenhour on Oct 6, 2021, 10:48
See idaholab/valhalla#4 for original issue. Description repeated below.
For melt pool dynamics, recoil pressure needs to be included.
The include of recoil pressure would make divergence of velocity nonzero near the interface, so some additional terms need to add to INS equations.
Add new features.
In GitLab by @cticenhour on Dec 14, 2021, 15:26
This issue is a reproduction of the archived freya#2 for SQA purposes. Please refer to that issue for any extended discussion that may exist beyond this description.
Adding simplified, temperature only, input files at both the engineering scale and microscale are required to identify the challenges and potential fixes to multiscale modeling in yittria
Input files only at this first stage, ideally using the internal MOOSE mesh capabilities
Start to implementing the multiscale / multiapp functionality needed for modeling SPS
In GitLab by @snschune on Dec 12, 2022, 16:39
The HomogenizedThermalConductivity
was changed and it's used quite a bit in Malamute.
Changes are straight-forward and capability is preserved.
Check out MOOSE PR #22927 and attempt to test MALAMUTE.
Prevents usage of any input file that uses HomogenizedThermalConductivity
In GitLab by @cticenhour on Oct 6, 2021, 11:38
In order to create MALAMUTE, Valhalla, Baldr, and Freya need to be transitioned to this code base.
Move Valhalla, Baldr, and Freya code to MALAMUTE. Preserve git history and issue history as much as possible for SQA.
New MALAMUTE features.
In GitLab by @cticenhour on Oct 6, 2021, 15:11
Merges valhalla-transition -> devel
This PR adds code formerly residing in Valhalla to MALAMUTE. The MALAMUTE Makefile and documentation configuration were also updated to accommodate the new code and new module dependencies. The repository issue templates were also moved to the correct location.
Refs #1
Closes #2
Closes #3
Closes #4
Refs #5
Closes #6
In GitLab by @cticenhour on Sep 2, 2021, 11:46
Merges sqa-init-1 -> devel
This MR:
Closes #1
In GitLab by @cticenhour on Dec 23, 2021, 23:06
Test coverage in MALAMUTE could be improved.
Look at https://malamute-dev.hpc.inl.gov/coverage/
Former Baldr objects added in !6 are not tested fully because their tests were skipped. These tests should be fixed.
Better test coverage.
In GitLab by @cticenhour on Aug 1, 2022, 10:53
Merges fixup-deprecated -> devel
Closes #34
This MR also commits automatic VSCode input file format changes that come from the MOOSE extension.
In GitLab by @cticenhour on Dec 14, 2021, 15:59
This issue is a reproduction of the archived freya#20 for SQA purposes. Please refer to that issue for any extended discussion that may exist beyond this description.
The phase-field model has been updated to include multiple defect species and the effect of defect species charge as well as applied electric field. An example file of the updated model needs to be added to facilitate multi-scale integration.
See reason.
Example of new phase field capability for facilitation of multi-scale development
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.