1% Release notes of the 3.0.2 version of `TFEL`, `MFront` and `MTest` 2% Thomas Helfer 3% 2017 4 5Version 3.0.2 of `TFEL`, `MFront` and `MTest` has been released on the 625th October, 2017. 7 8This is mainly a bug fix version of the `3.0` series. All tickets 9solved are described below. There are no known regressions. 10 11\newcommand{\mol}{\mathrm{mol}} 12 13# Tickets fixed 14 15## Ticket #93: Error declaring local variable 16 17In certain circumstances, parsing a variable type was not consistent 18with `C++` rules. For example, the following statement was not 19properly parsed: 20 21~~~~{.cpp} 22@LocalVariable tfel::math::tvector<Nss,tfel::math::tensor<3u,real> > mu; 23~~~~ 24 25For more details, see: <https://sourceforge.net/p/tfel/tickets/93/> 26 27## Ticket #92: Reading boolean values in `Data::read_value` is broken 28 29For more details, see: <https://sourceforge.net/p/tfel/tickets/92/> 30 31## Ticket #91: Parts of the implicit systems and jacobian matrix blocks by the `StandardElasticity` brick shall be inserted at the beginning of the `@Integrator` block, not at the end 32 33For more details, see: <https://sourceforge.net/p/tfel/tickets/91/> 34 35## Ticket #90: Wrong test on `BOOST_VERSION` version in `bindings/python/include/TFEL/Python/SharedPtr.hxx` 36 37For more details, see: <https://sourceforge.net/p/tfel/tickets/90/> 38 39## Ticket #89: StandardElasticity: bug when only one the plane stress modelling hypotheses is selected 40 41For more details, see: <https://sourceforge.net/p/tfel/tickets/89/> 42 43## Ticket #88: Error when treating axial growth: the axis along the growth is wrong 44 45The main axis for the axial growth shall be the second direction of 46orthotropy, as described in the documentation, not the third one 47as implemented in versions \(3.0\) and \(3.0.1\). 48 49For more details, see: <https://sourceforge.net/p/tfel/tickets/88/> 50 51## Ticket #87: The correction of the axial growth modifies all the stress free expansion treated so far 52 53For more details, see: <https://sourceforge.net/p/tfel/tickets/87/> 54 55## Ticket #86: The material laws are not available in the `ComputeStress` block in the `RungeKutta` DSL 56 57The material laws (declared for example via the `@MaterialLaw` 58keyword) were not available without extra qualification in the 59`ComputeStress` block when using the `RungeKutta` DSL: one have to add 60the `mfront::` qualifier in front of the material law. 61 62The problem is a missing call to `writeMaterialLaws` in the 63`writeBehaviourParserSpecificMembers` member function of the 64`RungeKuttaDSLBase` class. 65 66For more details, see: <https://sourceforge.net/p/tfel/tickets/86/> 67 68## Ticket #85 Add support for an in plane "relocalisation strain" in behaviours laws 69 70The `@Relocation` keyword can be used to impose a boundary condition 71specific the fuel performances describing the rigid body translation 72of fuel pellet fragment as an additional strain. 73 74- an external state variable name. 75- a string giving an mfront file implementing a relocation model. 76 77### Modelling hypotheses affected 78 79This keyword is only effective in: 80 81- axisymmetrical generalised plane strain. 82- axisymmetrical generalised plane stress. 83- generalised plane strain. 84- plane strain. 85- plane stress. 86 87No expansion are added in the tridimensional and axisymmetrical 88modelling hypotheses. 89 90### Physical description 91 92The value of the relocation expansion \(r\) is converted in an 93additional expansion in the radial and orthoradial directions: 94 95\[ 96\left\{ 97\begin{aligned} 98\frac{\Delta\,l_{r}}{l_{r}} &= \frac{r}{2} \\ 99\frac{\Delta\,l_{\theta}}{l_{\theta}} &= \frac{r}{2} 100\end{aligned} 101\right. 102\]. 103 104This additional expansion is such that it does not create any stress 105in the fuel pellet for an isotropic elastic material with constant 106material properties. 107 108The axial axis is the second direction in \(1D\) hypotheses and the 109third direction in \(2D\) hypotheses. 110 111### Examples 112 113~~~~ {#Relocation .cpp} 114// relocation defined by an external model 115@Relocation 'UO2Relocation.mfront'; 116~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 117 118~~~~ {#Relocation2 .cpp} 119// relocation defined by an external state variable 120@ExternalStateVariable real r; 121r.setEntryName("Relocation"); 122@Relocation r; 123~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 124 125For more details, see: <https://sourceforge.net/p/tfel/tickets/85/> 126 127## Ticket #84: Check the `NTENS` value in the `Abaqus` interface 128 129The value of the `NTENS` value was not used to check that the function 130called was consistent with the modelling hypothesis used. 131 132For more details, see: <https://sourceforge.net/p/tfel/tickets/84/> 133 134## Ticket #82: Python interface is broken if no material name if not defined 135 136For more details, see: <https://sourceforge.net/p/tfel/tickets/82/> 137 138## Ticket #81: Have two versions of MFront in the same environment 139 140In `cmake`, the `TFEL_APPEND_VERSION` option will append the version 141number to the names of: 142 143- The executables. 144- The libraries. 145- The python modules. Note that, to comply with `python` restriction 146 on module' names, the characters `.` and `-` are replace by `_` and 147 that only the first level modules are affected. 148- The directories in the `share` folder. 149 150The headers are installed in a subforder named `TFEL-${TVEL_VERSION}`. 151 152For example, if the `TFEL` version is `3.0.2-dev`, using 153`TFEL_APPEND_VERSION` opion will generate: 154 155- The `mfront-3.0.2-dev` executable. 156- The `libTFELMaterial-3.0.2-dev.so` library. 157- The `mtest_3_0_2_dev` `python` module. 158- The `tfel_3_0_2_dev.material` `python` module. In this case, the 159 second level (`material`) is not affected. 160 161This allows multiple executables to be installed in the same 162directory. 163 164### The `tfel-config` tool 165 166The `tfel-config` tool has been modified to take this 167option appropriately. For example: 168 169~~~~{.bash} 170$ tfel-config-3.0.2-dev --includes 171-I/tmp/install/include/TFEL-3.0.2-dev 172$ tfel-config-3.0.2-dev --libs --material 173-L/tmp/install/lib -lTFELMaterial-3.0.2-dev -lTFELMath-3.0.2-dev -lTFELUtilities-3.0.2-dev -lTFELException-3.0.2-dev 174~~~~ 175 176### Modifications to `mfront` 177 178`mfront` has been modified to call the appropriate `tfel-config` 179executable. 180 181For more details, see: <https://sourceforge.net/p/tfel/tickets/81/> 182 183### An helper function for importing `TFEL` modules 184 185~~~~{.python} 186import os, importlib 187 188def python_module_version(v): 189 """Return the python module extension from the TFEL version""" 190 return v.replace('.','_').replace('-','_') 191 192def import_tfel_module(n,*v): 193 """Try to import a tfel module, taking into account the TFEL_VERSION environment variable.""" 194 if not n: 195 ImportError('Empty module name') 196 m = n.split('.') 197 if not v: 198 env = os.environ; 199 if('TFEL_VERSION' in env): 200 v = env.get('TFEL_VERSION') 201 m[0] = m[0]+'_'+python_module_version(v) 202 elif len(v)==1: 203 m[0] = m[0]+'_'+python_module_version(v[0]) 204 else: 205 ImportError('Invalid number of arguments') 206 return importlib.import_module('.'.join(m)) 207~~~~ 208 209## Ticket #80: Adding the possiblity to compile a law using python module 210 211`MFront` relies on external tools, called generators, for this step 212(this semantic is the same than the one used by `cmake`). 213 214The only available generator is currently the `Makefile` generator, 215handled by the `MakefileGenerator` class. This generator can be used 216as follows: 217 218~~~~{.python} 219import mfront 220dsl = mfront.getDSL("Chaboche.mfront") 221 222dsl.setInterfaces(['castem']) 223dsl.analyseFile("Chaboche.mfront") 224dsl.generateOutputFiles() 225 226m = mfront.MakefileGenerator() 227m.exe(dsl.getTargetsDescription()) 228~~~~ 229 230The `exe` methods provides several overloads and may accept an 231additional argument of type `GeneratorOptions` which let the user 232specifiy the optimisation level to be used. 233 234For more details, see: <https://sourceforge.net/p/tfel/tickets/80/> 235 236## Ticket #79: `Cyrano` interface: bug in `CyranoBehaviourHandler` class. Missing test. 237 238The problem appeared when local substepping is enabled. 239 240This feature was not tested for the `Cyrano` interface, which 241explains why this regression has not been detected so far. 242 243The problem was fixed and appropriate test were added. 244 245For more details, see: <https://sourceforge.net/p/tfel/tickets/79/> 246 247## Ticket #78: Fix transpose of `st2tost2` when using rvalue reference 248 249The definition of the transpose of `st2tost2` was broken when the 250argument was an rvalue reference. 251 252For more details, see: <https://sourceforge.net/p/tfel/tickets/78/> 253 254## Ticket #77: operators `*=` and `/=` are broken for fourth order tensors 255 256The operators `*=` and `/=` are broken for fourth order tensors: the 257`std::is_same` metafunction return value must be accessed with the 258`value` member, not the `cond` member. This was a reminiscence an old 259remove class called `tfel::meta::IsSame` which was removed in 260`TFEL-3.0`. 261 262For more details, see: <https://sourceforge.net/p/tfel/tickets/77/> 263 264## Ticket #75: Support for `python3` in the python interface 265 266The code generated by mfront with the python interface is not 267compatible with `python3`. The trouble is linked to changes in the 268module declaration. See 269<https://docs.python.org/3/howto/cporting.html> for details. 270 271For more details, see: <https://sourceforge.net/p/tfel/tickets/75/> 272 273## Ticket #73 AbaqusExplicit: wait for tasks termination when the `ThreadPool` threading model is used 274 275The `ThreadPool` class now has a `wait` method that stops the main 276thread up to tasks completion. This method is now called at the end of 277the integration in the `AbaqusExplicit` interface when the 278`ThreadPool` threading model is used. 279 280For more details, see: <https://sourceforge.net/p/tfel/tickets/73/> 281 282## Ticket #72: Error at compilation of documentation 283 284The latex documents declared a unnecessary dependency to the 285`stmaryrd` package. This package became outdated in recent `LaTeX` 286distributions causing some portability issues. This dependency has 287been removed. 288 289The inclusion of the `babel` package was missing in the 290`docs/presentations/mfront-formation-tp/tp.tex.in` file. 291 292For more details, see: <https://sourceforge.net/p/tfel/tickets/72/> 293 294## Ticket #69: `@Profiling` true; Error in cygwin 295 296Under Windows, the `__declspec(dllexport)` attribute does not 297propagate to inner structures, wheres the visibility flags used under 298`POSIX` systems does. This attribute is now set also on the 299`BehaviourProfiler::Timer` structure. 300 301For more details, see: <https://sourceforge.net/p/tfel/tickets/69/> 302 303## Ticket #70: `PLASTIC` + `MFRONT` in `CalculiX` 304 305`CalculiX` provides two interfaces to `ABAQUS` `umat` behaviours. In 306versions prior to 2.12, those interfaces are not fully compatible with 307`ABAQUS` concerning various checks. The issue has been reported to 308`CalculiX` developers. 309 310To circumvent those issues, the `MFRONT_ABAQUS_NORUNTIMECHECKS` flag 311has been added. This flag desactivates: 312 313- checks related to the number of material properties (value of 314 `NPROPS`) 315- checks related to the number of state variables (value of `NSTATV`) 316- checks related to usage of the behaviour in finite strain analysis 317 (`KSTEP`) 318 319All those checks may fail with the `ABAQUS` and `ABAQUSNL` interfaces 320in `CalculiX` for reasons described in the previous posts. This flag 321can be set as follows: 322 323~~~~{.bash} 324mfront --obuild --interface=abaqus -D MFRONT_ABAQUS_NORUNTIMECHECKS SaintVenantKirchhoffElasticityTotalLagrangian.mfront 325~~~~ 326 327For more details, see: <https://sourceforge.net/p/tfel/tickets/70/> 328 329## Ticket #67 A suffix to the material name is required (`abaqus` interface) 330 331The material name in `Abaqus/Standard` and `Abaqus/Explicit` are now 332expected to have the following form: 333`LIBRARY_FUNCTION_HYPOTHESIS_IDENTIFIER`. 334 335The last part (`_IDENTIFIER`) is optional. 336 337For more details, see: <https://sourceforge.net/p/tfel/tickets/67/> 338 339## Ticket #64: Change the library prefix to "cyg" under cygwin 340 341The default library prefix under cygwin has been changed to `cyg` 342(rather than `lib`) to follow the standard conventions of this 343environment. 344 345For more details, see: <https://sourceforge.net/p/tfel/tickets/84/> 346 347## Ticket #63: Error cygwin (make) 348 349Compiling `MFront` under `Cygwin` was broken because the `_GNU_SOURCE` 350macro was not defined in the following headers: 351 352- `mfront\tests\properties\test-cxx.cxx` 353- `src\System\ProcessManager.cxx` 354- `src\System\SignalManager.cxx` 355 356For more details, see: <https://sourceforge.net/p/tfel/tickets/83/> 357 358## Ticket #58: Fix initialisation of an array of parameters 359 360For more details, see: <https://sourceforge.net/p/tfel/tickets/58/> 361 362## Ticket #57: More robust detection of python versions: avoid mismatch between the python libraries, the python interpreter and the boost python library 363 364For more details, see: <https://sourceforge.net/p/tfel/tickets/57/> 365 366## Ticket #54: Bug in StensorFromTinyVectorView: standard assignement fails 367 368For more details, see: <https://sourceforge.net/p/tfel/tickets/54/> 369 370## Ticket #53: Add comments handling in parameters txt files 371 372For more details, see: <https://sourceforge.net/p/tfel/tickets/53/> 373 374## Ticket #52: More robust handling of parameters txt file 375 376For more details, see: <https://sourceforge.net/p/tfel/tickets/52/> 377 378## Ticket #20 Allow `MFront` to work under `Windows` without requiring `MSYS` 379 380The documentation describing how to install `TFEL` on `Windows` has 381been updated: The main difficulty associated with building 382`TFEL/MFront` on [Windows plateform](http://windows.microsoft.com) is 383the lack of an unified build environment which must be set up by the 384user. 385 386The installation on [Windows plateform](http://windows.microsoft.com) 387is thus described in the following pages: 388 389- [Installation based on `cmake` and `Visual Studio`](http://tfel.sourceforge.net/install-windows-VisualStudio.html). 390- [Installation based on `cmake` and `MinGW` (as packaged with `Cast3M` `2017`)](http://tfel.sourceforge.net/install-windows-Cast3M2017.html). This 391 tutorial can easily be adapted to other versions of `MinGW`, without 392 requiring `Cast3M` to be installed. 393- [Installation based on `MSYS`](http://tfel.sourceforge.net/install-windows-msys.html). 394 395The two first solutions does not depend on `MSYS`. 396 397For more details, see: <https://sourceforge.net/p/tfel/tickets/20/> 398 399## Ticket #17: Add physical constants from CODATA 400 401Various physical constants are now available. The values are extracted from: <http://physics.nist.gov/cuu/Constants/index.htm> 402 403| Symbol | Description | Value | Unit | 404|-----------+---------------------------+------------------------------+------------------------| 405| \(\mu\) | Atomic mass constant | \(1.660539040\,.10^{-27}\) | \(kg\) | 406| \(N_{a}\) | Avogadro constant | \(6.022140857\,.10^{23}\) | \(\mol^{-1}\) | 407| \(k_{b}\) | Boltzmann constant | \(1.38064852\,.10^{-23} \) | \(J.K^{-1}\) | 408| \(G_{0}\) | Conductance quantum | \(7.7480917310\,.10^{-5}\) | \(S\) | 409| \(e_{0}\) | Electric constant | \(8.854187817\,.10^{-12}\) | \(F.m^{-1}\) | 410| \(m_{e}\) | Electron mass | \(9.10938356\,.10^{-31} \) | \(kg\) | 411| \(eV\) | Electron volt | \(1.6021766208\,.10^{-19}\) | \(J\) | 412| \(e\) | Elementary charge | \(1.6021766208\,.10^{-19}\) | \(C\) | 413| \(F\) | Faraday constant | \(96485.33289\) | \(C.\mol^{-1}\) | 414| \(a\) | Fine-structure constant | \(7.2973525664\,.10^{-3}\) | | 415| \(R\) | Molar gas constant | \(8.3144598\) | \(J.\mol^{-1}.K^{-1}\) | 416| \(s\) | Stefan-Boltzmann constant | \(5.670367\,.10^{-8}\) | \(W.m^{-2}.K^{-4}\) | 417 418For more details, see: <https://sourceforge.net/p/tfel/tickets/17/> 419 420### `C++` 421 422The physical constants are available as constexpr static members of 423`tfel::PhysicalConstants` class defined in the 424`TFEL/PhysicalConstants.hxx` header. 425 426~~~~{.cpp} 427using Cste = tfel::PhysicalConstants<real>; 428const auto R = Cste::R; 429~~~~ 430 431### Python 432 433The physical constants are available as members of the 434`tfel.PhysicalConstants` class, as follows: 435 436~~~~{.python} 437from tfel import PhysicalConstants as Cste 438print(Cste.Na) 439~~~~ 440 441<!-- Local IspellDict: english --> 442