Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 30 2019 22:44
    OVGULIU forked
    OVGULIU/JuliaFEM.jl
  • Jan 30 2019 22:44
    OVGULIU starred JuliaFEM/JuliaFEM.jl
  • Jan 30 2019 18:53
    ahojukka5 closed #16
  • Jan 30 2019 18:53
    ahojukka5 commented #16
  • Jan 30 2019 18:51

    ahojukka5 on fix_16

    (compare)

  • Jan 30 2019 18:51

    ahojukka5 on master

    Read med file exported from Gms… (compare)

  • Jan 30 2019 18:51
    ahojukka5 closed #17
  • Jan 30 2019 17:14
    ahojukka5 opened #17
  • Jan 30 2019 17:14

    ahojukka5 on fix_16

    Read med file exported from Gms… (compare)

  • Jan 30 2019 14:28
    ahojukka5 commented #16
  • Jan 30 2019 14:22
    ahojukka5 commented #16
  • Jan 30 2019 14:22
    ahojukka5 commented #16
  • Jan 30 2019 14:20
    ahojukka5 commented #16
  • Jan 29 2019 13:10
    Chaztikov edited #228
  • Jan 29 2019 13:07
    Chaztikov commented #228
  • Jan 29 2019 13:07
    Chaztikov commented #228
  • Jan 28 2019 15:47
    dyushu starred JuliaFEM/Mortar2D.jl
  • Jan 28 2019 11:18
    Chaztikov commented #228
  • Jan 28 2019 11:17
    Chaztikov commented #228
  • Jan 28 2019 11:09
    Chaztikov opened #228
Tero Frondelius
@TeroFrondelius
@thelfer morning. Do you have these example models already online somewhere? I mean the example mfront files Norton.mront.
Tero Frondelius
@TeroFrondelius
@thelfer do you know what means the error: MFrontLock::MFrontLock: semaphore creation failed?
Tero Frondelius
@TeroFrondelius
The first working version of the MFrontInterface.jl package: https://github.com/JuliaFEM/MFrontInterface.jl. Currently only x86 linux version.
thelfer
@thelfer
@TeroFrondelius Examples are distributed with MFront. However, you should better distribute it with the tests.
@TeroFrondelius Concerning the error message, MFrontuses a global lock to write shared files when run in parallel. This message says that this lock is already in used. Most of the times this error means that MFront crashed and left the lock without releasing it. It is a file located in /dev/shm/ which must be removed by hand.
thelfer
@thelfer
@TeroFrondelius Great for the MFrontInterface.jl interface
Tero Frondelius
@TeroFrondelius
tero@tero-Dell-System-XPS-L321X /tmp/tfel-sources/mfront/tests $ find /** -name .mfront
behaviours/AbaqusAxialGrowth2.mfront
behaviours/AbaqusAxialGrowth.mfront
behaviours/AbaqusOrthotropicElastic2.mfront
behaviours/AbaqusOrthotropicElastic.mfront
behaviours/AbaqusOrthotropicSwelling2.mfront
behaviours/AbaqusOrthotropicSwelling.mfront
behaviours/AgeingBurger.mfront
behaviours/AnistropicLemaitreViscoplasticBehaviour.mfront
behaviours/AxialGrowth2.mfront
behaviours/AxialGrowth3.mfront
behaviours/AxialGrowth.mfront
behaviours/bricks/FiniteStrainSingleCrystal/FiniteStrainSingleCrystal_NumericalJacobian.mfront
behaviours/bricks/FiniteStrainSingleCrystal/FiniteStrainSingleCrystal.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityNortonTest_nj.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityPlasticityTest10_na.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityTest1.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityPlasticityTest14_na.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityPlasticityTest14_nanj.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityTest4.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityPlasticityTest15.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityTest6.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityPlasticityTest4_nj.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityNortonTest4_nj.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityPlasticityTest13.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityPlasticityTest7_nj.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityNortonTest8.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityPlasticityTest13_na.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityPlasticityTest14.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityPlasticityTest4.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityIsotropicDamageHookeLaw.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityPlasticityTest12_nj.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityHyperbolicSineTest2.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityPlasticityTest13_nj.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityNortonTest9.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityPlasticityTest_na.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityPlasticityTest_nj.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityPlasticityTest.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityIsotropicDamageHookeLaw2.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityNortonTest3_nj.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityPlasticityTest2_nj.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityNortonTest3.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityHyperbolicSineTest.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityOrthotropicNortonTest.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityPlasticityTest13_nanj.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityPlasticityTest9_nanj.mfront
behaviours/bricks/StandardElastoViscoPlasticity/StandardElastoViscoPlasticityOrthotropicNortonTest_nanj.mfront
behaviours/bricks/StandardElastoViscoPlasticity/Standar
@thelfer Cool amount of tests. Do you already have a makefile in place to write a single or few shared object libraries out of these tests? I don't want to waste energy, if someone already did the work.
thelfer
@thelfer
@TeroFrondelius In the master branches, there are indeed more than 15 000 unit tests. I am not sure of what you want to do. If you want to test if your MFront binaries are ok, then just use make check. Note that the time required exceeds the allowed time for free project in Travis...
Tero Frondelius
@TeroFrondelius
@thelfer I would like to build the needed so-files for MFrontInterface.jl testing. Of course, we won't need all of tests from Mfront, but some subset. Although sometimes it is just easier to take full binary if there is already a Makefile to produce it.
Tero Frondelius
@TeroFrondelius
Could someone check that I didn't made any type piracy. Also all other comments welcome. If possible, please comment the pull request directly. JuliaFEM/MFrontInterface.jl#4
Tero Frondelius
@TeroFrondelius
@thelfer is there another command than make check for just building the test dependencies?
thelfer
@thelfer
@TeroFrondelius Not for the moment. However, one just have to write a script which launches MFront, right ?
Tero Frondelius
@TeroFrondelius
@thelfer it would be really cool to write julia macro to transform MFront C++ tests to julia tests. Do you think it would be possible? I haven't written any macros myself, but basically they are meant for this exact use case (transform code).
Tero Frondelius
@TeroFrondelius
@thelfer here is the tool to make the transform: http://mikeinnes.github.io/MacroTools.jl/stable/sourcewalk/
Tero Frondelius
@TeroFrondelius
@thelfer you have check(d.behaviour == "ParameterTest", "invalid behaviour name"); in a file MFrontGenericInterfaceSupport/tests/ParameterTest.cxx. How I can access these parameters from Julia side? I was going to replicate your testfile to MFrontInterface.jl
thelfer
@thelfer
@TeroFrondelius Sorry. Very busy week. I still don't get what you want to do. Personnaly, I would just focus on testing the Julia bindings of MGIS, that only requires compiling a few MFront file.

@TeroFrondelius The bindings are not documented yet, so you have to rely on the bindings sources. In the bindings/julia/src/Behaviour.cxx file, you have the following lines:

  m.add_type<Behaviour>("Behaviour")
 ...
      .method("get_parameters", [](const Behaviour &b) { return b.params; });

As you see, I have wrapped a get_parameters methods which returns an array containing the name of all parameters.

Tero Frondelius
@TeroFrondelius
@thelfer no problem, I was busy as well. Regarding what I want to do: I don't know myself. Thanks for the answer.
Tero Frondelius
@TeroFrondelius
@thelfer I tried to cross compile libBehaviour in mgisBuilder script. Linux version almost works (for some reason mfront crashes in Travis), but real problem is Windows and other non-native binaries. I can build Win32 mfront binaries, but I cannot run it. Thus I don't have mfront available to set up the makefiles for libBehaviour compiling. While writing this I realized that I can try wine.
thelfer
@thelfer
@TeroFrondelius Indeed wine may work. IMHO, cross-compiling is generally easy, but testing is really hard.
Matt Campbell
@micampbell
has anyone tried to get the example, 3d_frame.jl, running recently? we are newbies and finding that it crashes on the run! statement. This is after trying on linux, and 2 windows machines. It says please submit a bug report that starts "Exception: EXCEPTION_ILLEGAL_INSTRUCTION at 0xe7de05 --n at ....julia\packages\TimerOutputs\7zSput.jl:216 [inlined]". Should I submit this here? or on github. (P.S. - we're using 1.1.0)
Matt Campbell
@micampbell
the other two examples (2d_hertz, linear_static) work fine, but 3d_frame and linear_static seem to be perhaps for older Julia versions
Tero Frondelius
@TeroFrondelius
You are probably right, maybe the 3d_frame example is outdated. Maybe you can fix it by following the 2D example? @maikkirapo can you help?
Matt Campbell
@micampbell
we are not clear what to do with the error. I understand what you are saying: that the problem is likely in the setup in the old Julia 0.7 examples, but I'm not familiar enough with JuliaFEM to know why its not working. I really think having more than one example would be good for this project. So, some help maybe?
Tero Frondelius
@TeroFrondelius
@micampbell it looks like that we haven't ported the beams packet to work in julia 1.0 environment. It's really cool if the 2D example works. Unfortunately the main developer of the beam package Ville decided to work elsewhere and thus we haven't ported the package to julia 1.0 yet. Also I fully agree that we should have more examples. However, we have the same exact problem than others. If you find
I was going to say: If you use research funding to fund the activities and people are busy doing their research who will have the time and what is his/her motivation to make examples? Everybody appreciates good documentation, but seldomly people are ready to pay for it.
Tero Frondelius
@TeroFrondelius
Anyway we are open to get any help we can get in the form of pull request. It's clearly a TimerOutput.jl package problem. The first step solving the issue would be commenting out/removing TimerOutput.jl from the example.
Matt Campbell
@micampbell
thanks, we're looking into it, Neil (@BGFGB) may write here regarding our efforts as well
Marja Rapo
@maikkirapo
I tried to run the example on Julia v. 0.7.0 on a mac computer, but the same problem occured for me: Julia stops at the run! statement. Next I will try also using an older version of JuliaFEM if it's possible.
Matt Campbell
@micampbell

okay, we've commented out the timing problem, which led to the real issue:
UndefVarError: get_quadrature_points not defined
get_integration_points(::Problem{Beam}, ::Element{Seg2}) at beam3d.jl:16
assemble_elements!(::Problem{Beam}, ::Assembly, ::Array{Element{Seg2},1}, ::Float64) at beam3d.jl:78
assemble!(::Problem{Beam}, ::Float64) at assembly.jl:85...

so, the problem is that there is no longer on overload to the function FEMBase.get_quadrature_points that takes the one argument. this is line 16 of beam3d.jl.

Any ideas how to fix? It is clearly not in the example file, but rather deeper in the library.

Marja Rapo
@maikkirapo
@micampbell I tracked the function get_quadrature_points
It seems to be located in a JuliaFEM repository called FEMQuad.jl
Marja Rapo
@maikkirapo
In FEMBase FEMQuad is imported, so to me the function should be recognized when it is called from FEMBase. Maybe there is some issue with exporting the function to FEMBase.
Matt Campbell
@micampbell
@maikkirapo okay, not sure. Since I'm just coming into this group, I'm unsure how to proceed. I'm guessing there was change in some code that was used by other examples that is preventing this from working.
Marja Rapo
@maikkirapo
@micampbell Yes, i think too that the code has been changed and the problem is not occuring because of the new Julia version. I will try to find out more of why the function call does not work since that is the only clue for now.
Marja Rapo
@maikkirapo
To me it seems that JuliaFEM does not include the module FEMQuad at all:
julia> using JuliaFEM
julia> using JuliaFEM.FEMBase
julia> using JuliaFEM.FEMBeam
julia> using JuliaFEM.FEMQuad
ERROR: UndefVarError: FEMQuad not defined
Matt Campbell
@micampbell
so, not this is not due to the change from 0.7 to 1.1, but rather an inadvertent deletion? or does it just need to be added via Pkg?
Marja Rapo
@maikkirapo
I'm not entirely sure if the version has something to do with it, but I did try to run the example with Julia 0.7 and the same issue happened. FEMQuad seems to be a module of JuliaFEM and it is installed with JuliaFEM since it's folder exists in the Julia packages folder. But for some reason seems that it's not exported properly when JuliaFEM is recompiled.
This warning message might have something to do with it:
julia> using JuliaFEM
[ Info: Recompiling stale cache file /Users/mrapo/.julia/compiled/v1.0/JuliaFEM/JKouA.ji for JuliaFEM [f80590ac-b429-510a-8a99-e7c46989f22d]
WARNING: using FEMBasis.interpolate in module FEMBase conflicts with an existing identifier.
WARNING: could not import Base.start into JuliaFEM
WARNING: could not import Base.next into JuliaFEM
WARNING: could not import Base.done into JuliaFEM
WARNING: could not import Base.endof into JuliaFEM
Marja Rapo
@maikkirapo
So I got the function get_quadrature_points to show up when JuliaFEM is used as it should, but the same issue is still happening (Julia crashes at the run! statement). So now I'm trying to locate where the issue is rising from. I wrote a question to Julia discourse: https://discourse.julialang.org/t/prints-wont-show-up-when-debugging-a-function/27105
Maybe someone here knows if there are some limitations in doing changes to the JuliaFEM package, because my changes are not showing up as I explained in the question.
Matt Campbell
@micampbell
I think you have to remove the timer statements and then debugging should be easier
Matt Campbell
@micampbell
we got it running by :
  1. line 17 of beam3d.jl - changed FEMBase to FEMQuad ("return FEMQuad.get_quadrature_points(Val{:GLSEG3})")
  2. line 104 of beam3d.jl - there was no overload for '-', so we hacked it by just changing xi to xi[1]
  3. line 294 of solvers_modal.jl changed ucfirst to uppercasefirst
we are most confident of the last change as this is just replacing an archaic Julia function, but the second one is a hack, and we don't understand the variables. What about the first one? changing FEMBase to FEMQuad...does this make sense?
Matt Campbell
@micampbell
here are the answers we got. are they the same as before?
Natural frequencies [Hz]: [2.06, 2.06, 2.84, 5.65, 11.34, 11.35, 12.36, 12.64, 12.64, 14.76]
Tero Frondelius
@TeroFrondelius
@ahojukka5 can you comment? @micampbell can you make a pull request, it is a really convenient tool to make code reviews?
Matt Campbell
@micampbell
Yes, I will make a pull request for both FEMBeam and JuliaFEM. But I would like us to understand these fixes better.
  1. Does anyone have a record of the previous answers? do they match what I've posted?
'2. get_integration_points seems to be returning a tuple, (w, xi) where xi is also a tuple. Before was xi just a scalar?
Jukka Aho
@ahojukka5
Yes, before in 1d integration rules xi was just a scalar, but this inconsistency is fixed in newest FEMQuad.