Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Chapter 1 examples 3 and 4 on Windows don't match manual #7

Open
rudyverderber opened this issue Jul 25, 2020 · 31 comments
Open

Chapter 1 examples 3 and 4 on Windows don't match manual #7

rudyverderber opened this issue Jul 25, 2020 · 31 comments

Comments

@rudyverderber
Copy link

I am running v 18.2.0 on windows(Cygwin).

Example 4 strain plot does not match the manual.
image

If I compare the end of output with the output provided, then some of the data matches (reactions, syy) while other data is quite different (sxx, szz,...).
Windows v 18.2.0 (4 threads)
structure vessel page no. 1

    step no.      52                        loading press_te
    stresses                      
  elem  cent         sigma_xx            sigma_yy            sigma_zz
                     sigma_xy            sigma_yz            sigma_xz
                     eng_dens            mises               c1      
                     c2                  c3      

   4482      1      506.594039          -17.741709          286.431419
                     -2.553535           -0.022078            1.921170
                      0.715885          456.062444            0.000191
                    456.351623            1.000000

   4474      1      480.513163          -14.610743          283.216122
                     -9.351400           -0.081717            1.721647
                      0.572980          432.041989            0.000000
                    456.375580            3.000000

   4386      1      442.158376          -14.902190          271.616722
                     -9.310997           -0.081349            1.488040
                      0.494760          400.386261            0.000000
                    456.410385            3.000000

   4378      1      407.080909          -14.749421          261.135993
                     -7.569651           -0.066097            1.273996
                      0.427794          371.288015            0.000000
                    456.445213            3.000000

   4356      1      392.513550          -14.742283          256.767078
                     -6.472893           -0.056543            1.184288
                      0.401544          359.349361            0.000000
                    456.462631            3.000000

    output reactions totals only 'react nodes'
  elem  cent         sigma_xx            sigma_yy            sigma_zz
                     sigma_xy            sigma_yz            sigma_xz
                     eng_dens            mises               c1      
                     c2                  c3      

  4482       1      -39.714525          -15.523197          427.182573
                     -2.784839           -0.016338           -4.090779
                      0.532257          455.366465            0.000106
                    456.347299            1.000000

  4474       1      -54.500370          -14.905684          419.867807
                     -1.687214           -0.005847           -4.155487
                      0.536134          455.930570            0.000123
                    456.383119            1.000000

  4386       1      -61.520359          -15.062703          416.017625
                     -0.641290            0.004245           -4.181395
                      0.539251          456.148139            0.000134
                    456.418586            1.000000

  4378       1      -64.532751          -15.126680          414.374298
                     -0.145754            0.009050           -4.192618
                      0.541439          456.274807            0.000140
                    456.453797            1.000000

  4356       1      -65.199477          -15.145125          414.025162
                      0.011333            0.010312           -4.192903
                      0.542307          456.321216            0.000142
                    456.471345            1.000000


output reactions totals only 'react nodes'

 Totals:        -0.67329E+07        -0.19639E+07        -0.17632E+06


 Totals:     -0.67329387E+07     -0.19638856E+07     -0.17632312E+06

provided output_temp_dependent
Mac OS X 17.5.4

  elem  cent         sigma_xx            sigma_yy            sigma_zz
                     sigma_xy            sigma_yz            sigma_xz
                     eng_dens            mises               c1      
                     c2                  c3      

  4482       1      -39.714525          -15.523197          427.182573
                     -2.784839           -0.016338           -4.090779
                      0.532257          455.366465            0.000106
                    456.347299            1.000000

  4474       1      -54.500370          -14.905684          419.867807
                     -1.687214           -0.005847           -4.155487
                      0.536134          455.930570            0.000123
                    456.383119            1.000000

  4386       1      -61.520359          -15.062703          416.017625
                     -0.641290            0.004245           -4.181395
                      0.539251          456.148139            0.000134
                    456.418586            1.000000

  4378       1      -64.532751          -15.126680          414.374298
                     -0.145754            0.009050           -4.192618
                      0.541439          456.274807            0.000140
                    456.453797            1.000000

  4356       1      -65.199477          -15.145125          414.025162
                      0.011333            0.010312           -4.192903
                      0.542307          456.321216            0.000142
                    456.471345            1.000000


output reactions totals only 'react nodes'

 Totals:        -0.67329E+07        -0.19639E+07        -0.17632E+06

For example 3, I get the general cylinder stresses, 1 of 6 T stresses, and the reaction nodes. I cannot get the K quantities and 5 of 6 T stresses. What am I doing wrong?

ex3

Thank you! Rudy  
@rhdodds
Copy link
Owner

rhdodds commented Jul 25, 2020

Hi Rudy,

Thanks for the info.

I'll start looking at this ...

Would you please run the verification suites on your setup ?

Please get newest version from www.warp3d.net. This version uses Python 3 to drive execution of the verification suites in .../verification/run....py This change was made because most users never install Cygwin (so they have no Bash shell). I installed Python 3 into Cygwin a few weeks ago. The run..py codes execute ok.

Thanks,

Bob

@rudyverderber
Copy link
Author

rudyverderber commented Jul 26, 2020 via email

@rhdodds
Copy link
Owner

rhdodds commented Jul 26, 2020

Rudy,

======
On Jul 25, 2020, at 8:12 PM, rudyverderber [email protected] wrote:

Hi Bob,

I ran the run_tests and run_J_tests verification suites on 18.2.0 on Cygwin. The check values are correct to 6 or 7 places. ( I thought one test didn’t run due to MPI, but I couldn’t find it.)

I downloaded version 18.2.1.

  1. It is not quite clear to me if “Windows” is DOS style or Cygwin. I guess I got Cygwin to work, so I kept with it. Do you recommend DOS style or Cygwin?

  2. Run_windows/warp3d.exe simply returns in 18.2.1 on DOS, while it works on 18.2.0.

=> There is one Windows .exe as you have seen. Can be run under DOS or Cygwin environment. I use mostly Cygwin
since development work is done on Linux and macOS.

Prior to this release, the verification problems required Cygwin + Bash + Perl to run. Many Windows
users did not want to install Cygwin.

I rewrote the “driver” system to use only Python (3) last month. Windows users w/o Cygwin can
readily install Python 3 right from the Python web site. Run the verification suites in a
DOS command shell.

I installed Python3 from the Cygwin site and run the same run..py codes under the Bash shell.

=> Did you see the Quickstart Windows document ?

Bob

@rudyverderber
Copy link
Author

rudyverderber commented Jul 26, 2020 via email

@rhdodds
Copy link
Owner

rhdodds commented Jul 26, 2020

Hi Rudy,

A set of fixes in directory verification/test72 apparently got omitted.

Please get them from GitHub source this site or: https://www.dropbox.com/s/ule9thtpk6awepc/test72.zip?dl=0

Bob

@rudyverderber
Copy link
Author

rudyverderber commented Jul 26, 2020 via email

@rhdodds
Copy link
Owner

rhdodds commented Jul 26, 2020

Hi Rudy,

  1. By default, WARP3D runs Windows jobs in shared-memory parallel using
    the available number of threads on the processor.
    For a typical I7, this will be 4 "real" threads = 4 "physical cores" + 4 "hyperthreads".
    I normally run WARP3D jobs with the number of threads set = # physical cores -1 to
    leave one core for the (hundreds) of Windows OS processes.

  2. Please check your WARP3D distribution. In the verification directory (and sub directories),
    the only .perl files should be in directories hybrid_*** for checking MPI runs on Linux.
    All other .perl files were removed at 18.2.1.

Working on the examples 3 and 4 in chpt 1 now.

Bob

@rudyverderber
Copy link
Author

rudyverderber commented Jul 26, 2020 via email

@rhdodds
Copy link
Owner

rhdodds commented Jul 27, 2020

Hi Rudy,

  1. testK_2 continues to be a challenge. The solutions vary about 1% between runs and across platforms. I have looked for the bug off and on for about a year. Shows up with by Intel fortran and gfortran. I've used Valgrind and memcheck w/o success in locating the problem.

  2. I just ran (again) the run_tests.py and run_J_tests.py on W10, cygwin. Ran fine. The repository has the same versions I'm running. I note that your Cygwin Python is 3.6. My Cygwin Python is 3.8.3.
    Would you please (1) get the repository versions of the two run...py codes, (2) update your Cygwin Python to current version (3.8.3) ?

The issues you found for manual Chpt 1 example 3. I should provide 3 separate input files. (1) for internal
pressure loading, (2) for crack face pressure loading, (3) for just thermal loading. Then also 3 corresponding output files
for comparison. The computed results are fine and agree with those in the Tables in Chpt 1. Will get that straightened out and update example_3 files.

Bob

@rudyverderber
Copy link
Author

rudyverderber commented Jul 27, 2020 via email

@rudyverderber
Copy link
Author

rudyverderber commented Jul 27, 2020 via email

@rhdodds
Copy link
Owner

rhdodds commented Jul 27, 2020

Hi Rudy,

  1. The code run_tests.py in verification directory on GitHub does recognize Cygwin. That code has stms:

ver = sys.version_info
print("\n\n>>> Running with Python version: "
+ str(ver.major)+'.'+str(ver.minor))
if ver.major == 3 and ver.minor <= 4:
print('\n\n >>>>>>>>>>>>> Please upgrade to Python 3.5 or newer')
print(' Execution terminated\n\n')
exit(0)

os_name = platform.system()
windows = os_name == 'Windows'
linux = os_name == 'Linux'
osx = os_name == 'Darwin'
cygwin = False
if 'CYGWIN' in os_name: cygwin = True <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
....
....

if cygwin :
continuation = ';'
print(">>> Platform: Cygwin (Windows). Only Intel Fortran version supported\n" )
warp_name = '$WARP3D_HOME"/run_windows/warp3d.exe" '

  1. Example 3 in Chpt 1. Crack face loading. You are correct. I don't believe the elements incident on the front have the traction applied. However, that omission will not impact the solution more that a tiny fraction of a percent given the vanishing small area of those elements.

  2. Pre-processors. Post-processing of WARP3D results using the open-source ParaView code is our default go to solution and has been for 5+ years.

    For mesh generation, there does not exist (to my knowledge) an open-source code of the same extensive capabilities, runs on all 3 platforms,
    ....

We use Patran and many other users adopt FEMAP. Both are commercial and have very wide use. FEMAP outputs Patran neutral files which the patwarp program in our distribution processes. These codes build complete models: geometry, meshing, loadings and boundary conditions of all types. For specialized crack models, we use FEACrack which offers WARP3D as one solution option (we have no financial relationship with the FEACrack folks).

The open source code GMSH may provide some users with an adequate solution. We have a beta Python program which converts the Abaqus style *.inp file output by GMSH into a WARP3D input file. The code handles
tet4, tet10, hex8 and hex20 elements. We're developing some experience with GMSH but are not sure yet that it will impose many types of loading and boundary conditions. But at least the nodal coordinates, element types, and connectivities are translated. This may be sufficient for many users.

Bob

@rudyverderber
Copy link
Author

rudyverderber commented Jul 27, 2020 via email

@rhdodds
Copy link
Owner

rhdodds commented Jul 29, 2020

Hi Rudy,

Update: manual_examples_chpt1/example_3_linear

This directory has been substantially updated. Please download this entire subdirectory.
The RPV has 3 loadings: (1) internal pressure w/o crack face, (2) crack face pressure, (3) quadratic temperature field over wall thickness.

There are now 3 input files to solve each loading separately: warp3d_internal_pressure.inp, warp3d_crack_face_pressure.inp, warp3d_temperarure_gradient.inp.

The domain-integration integral input is now also in 3 separate files: domain_define_internal_pressure.inp,
domain_define_face_pressure.inp, domain_define_temperature_gradient.inp

Output files of results: woutput_internal_pressure, woutput_crack_face_pressure, woutput_temperature_gradient

The J, K, T-stress results for (1) internal pressure loading, (2) crack face pressure loading agree with those included in Manual Section 1.3 tables.

The J, K, T values for temperature gradient do not agree. After a day of investigation, to include running WARP3D versions back for 5 years, it seems the Section 1.3 values listed for the temperature gradient were entered incorrectly. Code from
years ago gives same J-values as current version.

I'm updating Section 1.3 for this issue and to cleanup some text/tables than can be better.

Best,

Bob

@rudyverderber
Copy link
Author

rudyverderber commented Jul 29, 2020 via email

@rudyverderber
Copy link
Author

rudyverderber commented Jul 29, 2020 via email

@rhdodds
Copy link
Owner

rhdodds commented Jul 30, 2020

Hi Rudy,

  1. Glad you got the new input files for Example 3 and have run them successfully.

  2. The output files have T33 values computed. But,* no* T33 values are included in Table 1.3.2. Only T11 values which are
    the so-called T-stress described in fracture mechanics papers. Computed using interaction integral and displacements.

  3. Don't forget also that the output file results have units J: kJ/m**2 (N/mm) and to get
    K in MPa sqrt(m), divide the output K values by sqrt(1000) since length units are mm in input.

    See pg. 1.2-20 of Manual, with paragraph starting: Physical units employed ....

    This is for your second email today re K values of 425.4 and 95.8. Divide each by sqrt(1000) to
    get 3.02 and 13.5 MPa sqrt(m).

  4. In the domain definition to compute Interaction Integral (II) values, not J values, we implemented a capability to define
    uniform pressure over the full crack face. This increases significantly the K and T values from the II since an analytic
    integration is used rather than working from equivalent nodal loads of the crack trace pressures. This is a "special case"
    since the pressure is uniform. Some folks have wanted additional, analytic forms of pressure to facilitate the
    computation of weight function values (i.e. quadratic, cubic, ... pressures).

    The domain integral to compute J for the face pressure uses an approximate integration based on the equivalent
    nodal forces from the face pressure -- which can vary how everything the user wants. The accuracy is ok and gets
    better with a more refined near front mesh.

Best,

Bob

@rudyverderber
Copy link
Author

rudyverderber commented Jul 30, 2020 via email

@rhdodds
Copy link
Owner

rhdodds commented Jul 31, 2020

Hi Rudy,

Example 3. Linear analyses. Temperature loading.

The J-value of 5.25 kJ/m**2 is output on the \theta_g=0 and 3^o planes for domains 15-20. Complete agreement at the 2 crack front locations and full path independence (you can check by computing domains 2-20).

The KI (plane-strain) value output is computed from this J-value. Printed value converted to MPa sqrt(m) is 1055/sqrt(1000) = 33.4 MPa sqrt(m). I'm right now correcting Section 1.2.3 in Manual and will look at the nonlinear problem next week.

Best,

Bob

@rhdodds
Copy link
Owner

rhdodds commented Aug 1, 2020

Hi Rudy,

Re: FEACrack verification document (.pdf)

I do not have the input files for the models described in this document. You may be able to secure one or more of them from Dr. Greg Thorwald at Quest Integrity Group (boulder, CO). Greg developed all the models in FEACrack and compared the computed fracture mechanics parameters from several FE codes, including WARP3D.

Best,

Bob

@rhdodds
Copy link
Owner

rhdodds commented Aug 2, 2020

Hi Rudy,

Updates....

  1. Updated manual pages for chapter 1, example 3 linear RPV analyses:
    https://www.dropbox.com/s/844nvao8d77e1vk/text.pdf?dl=0

2 See updated input/output files for the temperature only analyses. I had a left over
clad CTE = 0 from a study on CTE mismatch effects.

Best,

Bob

@rudyverderber
Copy link
Author

rudyverderber commented Aug 5, 2020 via email

@rudyverderber
Copy link
Author

rudyverderber commented Aug 5, 2020 via email

@rhdodds
Copy link
Owner

rhdodds commented Aug 5, 2020

Hi Rudy,

Suggestions for getting model and results in a simple to read format.

Model:

Manual Section 2.12.6 on Flat Model Description Files. Writes an ASCII or stream, fixed format file for the model. Very simple, easy to read, fast in compiled code and Python, tastes great-less filling, ....

Results:

Manual Section 2.12.4. Flat Text & Stream (Binary) Result Files.

Fixed format files (ASCII, stream) designed for simple reading into spreadsheets, by Python, fortran, C++, ...

These files contain all nodes or elements.

I thought you were using ParaView ? Our code warp3d2exii works quite well to create an Exodus II (*.exo)
file for the model+results from our Flat Model Description and Flat Results Files. The .exo should also be readable
Visit.

Bob

@rudyverderber
Copy link
Author

rudyverderber commented Aug 5, 2020 via email

@rhdodds
Copy link
Owner

rhdodds commented Aug 8, 2020

Hi Rudy,

  1. Revised/updated manual Section 1.2 including both linear and nonlinear analyses of the simplified RPV model.

       https://www.dropbox.com/s/21r3xpvwd8femsu/Section_1.2.pdf?dl=0

  2. Revised, updated inout, output supporting files are here (GitHub)

  3. "Blocks" in Exodus II files. It seems that (1) all elements in a block must be the same type and (2) elements
    may be defined in only 1 block. We decided to assign elements to blocks using (1). If the same material
    is used in multiple element types, how would that be handled for block assignments? Maybe we
    misunderstand the requirements for block assignments.

Best,

Bob

@rudyverderber
Copy link
Author

rudyverderber commented Aug 9, 2020 via email

@rhdodds
Copy link
Owner

rhdodds commented Aug 9, 2020

Hi Rudy,

  1. Fig. 1.2.16. I made that with Patran but can also use ParaView (just checked again).

    output model flat patran convention text file "model"
output flat element stresses

The "patran convention" just sets the element types in model file to those
used by Patran.

In Paraview, the results label to fringe plot is: C1_mat_val. This the accumulated,
equivalent plastic strain. For the "bilinear" plasticity model, see pg. 3.5-3 and 3.5-4.

There are 3 "slots" for material model dependent values in the usual stress output. C1, C2, C3 mat_val.
This is left over from before the output of material states variables was implemented.
The writeup for each material model describes the contents of C1_mat_val, C2_mat_val, C3_mat_val.

  1. We have an issue with ParaView since they changed rendering engines some versions back.
    I'm now using 5.8.1-RC2 on Linux and macOS.
    Try getting fringes for this model in the immediate crack front region.
    You will see very severe imaging artifacts sometimes called "stair casing".
    I've Googled for hours over the past few months for a solution but have drawn a blank.
    It must be caused by the huge difference in element sizes for crack type models.

    See: https://discourse.paraview.org/t/removing-staircase-artifacts-in-image-mesh/4494

    Patran doesn't have this issue.
    I simply set an appropriately small global tolerance value and artifacts are gone.

  2. ParaView database: years ago we opted for the Exodus II format since many of our analyses have 100s to 1000s of
    load(time) steps of results. And we like to make movies. BUT, we could never understand how to create a VTK
    Legacy file (just simple text or stream) without having to repeat the model definition before the results for each
    load(time) step. That requirement seemed unusual to us.

    The VTK legacy format would be much simpler for everyone rather than the Exodus .exo format.

  3. Initial conditions for models. See Section 2.9 Initial Conditions to set initial temperatures, stresses, ....
    In the RPV models, see these lines in the input files:

!
initial conditions
temperatures
nodes all temperature 288 $ steady-state operation
!

Best,

Bob

@rudyverderber
Copy link
Author

rudyverderber commented Aug 10, 2020 via email

@rhdodds
Copy link
Owner

rhdodds commented Aug 13, 2020

Hi Rudy,

T_{ref}

I re-read your question/comment about this. I think we take your T_{ref} = 0 implicitly in
WARP3D.

My question: does that impact only the scheme to input temperature dependent material
properties or does it somehow limit the modeling capability ?

Best,

Bob

@rudyverderber
Copy link
Author

rudyverderber commented Aug 13, 2020 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@rhdodds @rudyverderber