(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start': new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0], j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src= 'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f); })(window,document,'script','dataLayer','GTM-PM5M9PRG');
20 minutes read
5 December 2022

How to check if the FEA report is good?

20 minutes read

I’ve seen dozens of FEA reports done by others. Mostly because Customers asked me to verify them or provide an opinion if the calculations are any good. More often than not, I have to inform the person that asked, that the report they have has serious flaws…

The ability to briefly check an FEA report is really useful for managers and business owners. After all, you really want to make sure that the calculations you’ve ordered are good! But the same knowledge will help FEA specialist to make their reports even better!

There are some key things you want to pay attention to. And while some, will require at least a bit of knowledge and critical thinking, many can be verified by folks without deep engineering training.

Of course, as always, I will try to keep this as simple, and as easy to understand, as possible!

It’s not about nice images!

I’m absolutely in love with FEA aesthetics. I love animations of outcomes and good snapshots of interesting parts of the model. I mean, doesn’t this just look great?

Nicely looking FEA outcome 🙂

Judging by the reports I verified, I’m not alone in this love! Usually, FEA reports are full of such images.

Don’t get me wrong, I have nothing against images in reports… not only do they look great, but they also “prove” that you actually did the FEA calculations of the model (!).

But the value of the report is not in the images (sadly). Just think about it, you would not be able to tell if the above part is good or not based on that image.

Experience shows, that FEA reports often look like this:

  • Page 1: Who ordered what, how the model geometry looks like, what material is this part made of, and sometimes the loads that are considered in the analysis.
    • Pages 2-10: Lots of really nice model snapshots (sometimes with mesh “off” so you can’t really see the mesh quality).
      • Page 11: Summary stating something along the lines: “As can be seen in the report the analyzed part has sufficient capacity and/or is compliant with the code”.

      Sadly, the above is just wrong! I know quite a few design codes that allow using FEA… non of those allows us to judge the capacity of the model “based on the image”. To be honest, I can’t really imagine what that procedure would look like!

      I think that the above, approach is completely wrong. But it is still the most popular way of preparing FEA reports. And I even understand why is that. The idea is quite simple: you do the model, load it somehow, show the images with the “outcomes”, and “by the eye” judge that this “looks good”. But this is not how you should do this…

      Remember: FEA images look great, but they do not convey enough information to judge what is the outcome of the analysis!

      If the report contains mostly images without descriptions and outcome analysis for them… there is a very high chance, that this is not what you are searching for!

      Standards or design codes

      Engineering is pretty much “standardized”. This means, that if you want to “design something”, there are official documents (most of the time on a “national level”!) that dictate how you should do the design!

      This is a huge asset, as the standards require you to make certain activities, and give rules on how you should interpret the outcomes. Those requirements are there, even if the Customer is unaware of them! So when someone orders a design “by the ABC standard”, it’s the engineers’ responsibility to follow that code!

      This means that ordering design done by a decent code is actually beneficent. It gives the Customer a framework, that will be checkable later on (even if the Customer does not know that framework… it’s just there!).

      The standards I like the most:

      • Eurocodes! I’m from Europe, so Eurocodes would be my natural choice. Those are the civil engineering codes allowing you to calculate steel (including some stainless steel), concrete, wood, and other structures. Sadly, there are a lot of them (thousands of pages!) and you usually have to use a few at the same time. Still, their use goes far beyond civil engineering, especially since the Plates (EN 1993-1-5) and Shell (EN 1993-1-6) codes provide a very nice framework to perform nonlinear FEA analysis of almost anything, made from steel!
      • DNV-RP-C208. While Eurocodes are “national” (i.e. ratified by European Union Countries) DNV codes are privately done by Det Norske Veritas (https://www.dnv.com/). They are commonly used in offshore structures. What I like about them is, that they are way easier to read than Eurocodes, and even contain some simple examples! The one I’m referencing is for Nonlinear FEA Design.
      • EN 13445-3. While Eurocodes are the “civil engineering codes” of Europe, we do have a lot of other codes as well. I.e. pressure vessel industry uses this one (and many other industries have their own codes!). Usually, codes starting with “EN” can be just treated as a part of the “European code family”, and are quite similar in nature. It’s definitely good to know if your industry has a specific EN standard!
      • ASME VIII div. 2. I guess that at this point it’s getting obvious that I work in pressure vessels and shell structures. ASME is an American code with a scope similar to EN 13445. It also describes requirements for linear and nonlinear FEA design of pressure vessels (nonlinear calculations are in chapter 5).

      All those codes seem overwhelming?

      Don’t worry! If you just want to check the FEA report provided to you, you don’t really need to know the standard. All you need is to be aware that design codes exist, and that the report should follow one of those!

      Ok, so let’s get back to the report itself!

      Which code was used in the report?

      I’m a firm believer, that the FEA report should follow a selected standard/code. Usually, it’s the Customer’s choice, but some national rules may “force” a choice of a regional code on some occasions. It’s always good to specify it at the start of the project to avoid trouble later on!

      Of course, the Customer/Manager doesn’t really have to know the code. But it is definitely good to know that the codes exist and that you need to choose one for the design!

      Practically I’m always more than happy to help my Customers select a decent design code that “fits” what they need. But I have to say that nowadays, most often they just know what they need themselves.

      Even if you haven’t specified anything, and you are not sure what to choose – don’t worry! A good FEA specialist will ask you about it and guide you toward selecting a proper standard for your task.

      Good FEA report will specify, which design code was followed in the design.

      But be careful! It’s not enough to slap on the cover that design is done in accordance with a given code… it actually has to follow it, for it to be worth something!

      This is where the technical knowledge comes in!

      How to check if the report follows the code?

      As you already know, there are many codes, and realistically, it’s impossible to know them all! But I feel it’s also important to be sure, that the design was following the code procedure. How can you check this?

      The report should nicely describe Code-Use!

      Yea, it should be easy as that! I mean, codes are usually pretty thick (200-800 pages) with multiple chapters and rules. Almost always, they include more than a single check that the designer has to prove (stress, stability, fatigue, you name it!).

      This is why good reports always state the procedures used in a given part of the report. They should also show, what is the outcome of that procedure.

      So expect quite a few code references like “in accordance with EN 1993-1-6 chapter X.Y” etc. in the document. Even if you don’t know what those chapters are about, the fact that someone mentions a code is a good sign! And if you are making the report, adding the code reference is just a small fraction of the work, but it really helps your report to look professional and “stand out” – so I would advise you to do it if you are not doing this already.

      If you don’t know the code of the design, but you feel that something may be “off” with the references – don’t worry. You can always ask someone for help! Or just randomly look up a few chapter references to see if they match the report content (if equations look the same, etc.)

      Almost always outcome is a “number”!

      The engineering world likes numbers!

      Most code procedures end with the “code check”. It’s usually a simple equation where *something* is smaller than *something else*.

      One of those things comes from FEA analysis. It will be some sort of an outcome, like stress, deflection of a beam, plastic strain, etc. The other comes from the code, but the designer may have to calculate that value “by the code” to adjust it for a given case.

      So expect that each code check ends with “A<B which means that the requirement of chapter 14.3 is fulfilled”.

      There will be no vague descriptions like “as you can see, all is good”. Although this is a bit tricky if the outcome is “obvious” for an experienced engineer…

      Imagine a model where some check would be 1 < 1000! In such a case, it’s quite obvious that the check is ok… so the author of the report could writhe something about “as obviously seen”. Still, such situations don’t happen all that often. And writing the equation is good practice anyway.

      Sadly, this is not all black and white. I.e. ASME VIII div. 2 has a few checks that succeed when the analysis converges for a given “state” (I really dislike those!). Verification of such a check is a bit more tricky. It will simply end with a funny sentence like “since the analysis converged for the load case C, verification according to chapter 5.3 positive”. There will be no equation or numeric outcome. So clearly, this may sound “unspecific”. Still, those things happen rarely (I can only think about ASME from the top of my head).

      If you are not sure… ask!

      This is simple as that. If someone provided you with a report, and you are not sure about the code, or the checks look “vague” and “strangely unspecific”… ask about it!

      Again, you don’t need to know the code at all. Just ask which procedures designers used in the design (ask for chapter numbers or equation numbers from the code). The answer to this question usually suffices to know if someone did a good job. You will either get the chapter numbers that the designers used… or not!

      Feel that the report is incomplete?

      This is a bit more tricky! While you see what is in the report, you really don’t see what is not there (and maybe should be there).

      Usually, design codes divide the verification into a few “categories”. And you can ask about each one of those:

      • Stress design – this may have many names (plastic design, cross-section capacity, stress check), etc. I think that if you will get anything, you will most likely get this. Just think if all the components that should be checked, have been checked!
      • Stability design – this is all things “buckling”. There is a big chance something is compressed in your model. And if so, this may not fail due to stress, but rather much sooner because of buckling. All codes for design will have specific rules to check that (EN 1993-1-6 would call this LS3, ASME VIII div. 2 calls this “protection from buckling” etc.). I would be willing to guess this may be missing in many reports!
      • Fatigue analysis – if the load is applied in cycles, then there are rules that allow checking this. Those are separate from “stress design”. Oftentimes, such analysis may be excluded from the scope of the report, as fatigue assessment in complex cases is super time-consuming, so check if the report should have this in accordance with the agreement. And if it should… ask about it if this is missing!
      • Deformation checks – I’m reluctant here, as many FEA codes do not provide limits to how much things “can” deform to still be “ok”. But maybe it’s a good idea to discuss this with the folks who do the calculations. Even if this is not required, maybe there are practical limits that should be met. Just remember… everything deforms – zero is not a viable option!

      What is cool, is that the above nicely fits into the previous point. Each of the above checks has a “code procedure”. This means that you can do them “correctly”, but also “wrongly”. Always ask, which chapter was followed in verification in any of the above!

      Imagine a situation like this:

      You ask the report provider, how they did the “stress design”, and they reply that the images (the nice FEA ones!) in the report are the “stress design”… but you already know that the images are not enough after riding this article, so you ask: “great, which chapter in the code describes how you analyzed those outcomes and found the answer satisfactory?”. Check-mate!*

      *BTW, if anybody will tell you a chapter, and that code really describes how to derive capacity from nice images… please let me know!

      But this is even more effective with stability! It’s absolutely commonplace for people to use LBA (Linear Buckling Analysis) of about anything, to prove that something has sufficient buckling capacity. The vast majority of codes do not allow such checks! They are too primitive and too inaccurate! In such cases, always ask which code chapter specifies such verification… and you will see if the job was done the right way.

      How to check if the report follows the selected code?

      It should be obvious from reading the code. Expect quite a bit code references, and checks that usually look like A<B in the report. Those are the outcomes… not the colorful pictures!

      If you are not sure – ask about it! The report provider should answer which code procedures were used, but remember that you are not hiring them to train you on how to do such analysis. So be ready to read that section of the code yourself if you will still have doubts.

      It’s also good to remember that usually following things should be covered in report:

      • Stress design
      • Stability design
      • Fatigue analysis
      • Deformations

      Of course assuming that the scope was not limited or extended beyond what code requires (but you will know about that for sure).

      What if my industry doesn’t have any codes?

      I’m fully aware that there are industries where codes are not so dominant, or may not exist at all.

      Sadly, this makes things much more complicated!

      The absence of rules doesn’t mean that everything is acceptable (you wouldn’t need the FEA report in that case, right?). This means, that someone has to decide what is acceptable and what is not acceptable in some way.

      I think, that in such a case, you should select a “generic code” that you can use in many areas. EN 1993-1-5 and EN 1993-1-6 come to mind as good ideas.

      Otherwise, be ready for a discussion on the limits you are willing to accept, safety factors and load combinations needed in design, etc.

      Check boundary conditions!

      Sadly, I don’t have good news: this is a technical thing!

      While codes describe a lot, they will not inform the engineer how to properly support their model. And the most outrageous mistakes in analysis that I’ve seen were with model supports.

      There is no simple way you can check that if you don’t have sufficient engineering knowledge I’m afraid.

      But at least check, if the way the model is supported in the analysis is described somehow in the report. If you feel like it, you can also wonder if the model supports “make sense”.

      You can always ask about it too.

      The way the model is suported may be the most important part of the analysis!

      Design codes give no guidance on this – it is assumed that the engineer performing the analysis knows what to do!

      Check if this is described in the report, and if in doubt ask someone to help you understand if the supporting of that model “makes sense”!

      Check if all the loads are there!

      Here, we have to be realistic. You most likely won’t be able to check everything with loads… since you would literally have to write half of the report yourself again!

      Codes usually nicely describe how to calculate loads from earthquakes, wind, or snow. Those calculations can have several pages of weird equations.

      Funny enough, my experience is, that those are usually quite correct! I mean sure, there may be errors in following the code procedures, but you will have a very small chance of finding those anyway (unless of course, you have to validate the report… then check each and every equation and digit!).

      But check if all the loads that should be in the analysis are really there (i.e. someone did not forget the earthquake load completely!).

      Codes usually describe how to add loads up in so-called “load combinations”. Expect a list of those in the report, and take a look if those make sense. Usually, loads in those use “safety factors” (so are bigger than you would expect). Safety factor values vary between 1.1 to even 3.5 in some extreme cases. The most common values would be around 1.5 to 1.7 I would say.

      Checking loads will most likely be an unneded nightmare!

      To the point, that I’m not sure if this is what you want to focus on, unless you are charged with actually “veryfying” the report.

      But do check, if all various loads were consiedered, and if load combinations look reasonable (each code should describe those, so a code reference there is expected as well).

      Mesh quality

      I wonder if you were waiting for this part. I feel that many folks obsess about this. OK, I’ll admit that poor mesh quality can really make the outcomes “bad”. I would obsess far more about model supports, and about the code used in design.

      It’s hard to get a “feel” of how small mesh is “small enough”. You could of course do the mesh convergence study (more on it here), but if you just want to quickly check the report, that would be way too much work!

      It’s impossible to make a quick guide here (just like with supports really) but a few pointers:

      • Square mesh is better than triangles. I mean, even in a nice square mesh you may need to have a few triangles here and there – so don’t freak out. But as a rule, nice and “evenly looking” square mesh is usually better. In triangular mesh is used, make sure that those are “second-order elements” (they have 6 nodes) – 3 nodded linear ones aren’t that great, but they may work if there are so many of them, that the printed image is literally black with lines…
      • Think about a clean, orderly room. A nice mesh is “regular” not “chaotic”. If it looks nice, it’s most likely decent. Still, chaotic mesh doesn’t necessarily mean that it’s “wrong”… still I would trust the “nice mesh” more any day (even if only because someone cared enough and put extra effort into making it!).

      As for the mesh “size”, it may be a bit tricky, but I think I know how to help. Take a look at this image, and wonder which mesh size in your opinion looks “good enough”:

      Remember the number under the model you selected (doesn’t have to be accurate!). When you are ready, check on the horizontal axis where your number is. The chart will show you how big an error such mesh produced in nonlinear analysis (there is a separate curve for TRI and QUAD elements):

      I know that this is just a “rough guideline”, but at least it will give you a visual hint!

      Summary!

      We covered a lot of ground here, so I feel that a small summary is in order!

      I hope that this article will help you to better analyze FEA reports, and also to write good reports yourself!

      A few key points to remember:

      • Nice FEA pictures are not outcomes! They look nice, and it’s good to include some in the report, but this is not how the “real outcomes” look like!
      • Actual outcomes are code checks! This means first of all, that you should either select the code of your choice (which is preferable) or at least establish what criteria will be used in the analysis (which may be tricky to do!). Either way, the outcomes usually look like a check A<B and have a numerical value (so you know how much percent of model utility is “used”. There is no guessing involved!
      • If you are not sure if the report is done by the code… check for code references in the report, see if each analysis ends with some sort of “code check” and if you are not sure… ask! Also, make sure that everything that was in the scope of the analysis is actually verified (things like stress design, stability analysis, fatigue, deformations, etc.)
      • Pay attention to how the model is supported. Sometimes it is super-easy, but most mistakes I found come from this area, and those are also “the worst” in my opinion! If you are not sure how the model is supported, ask. And if you feel unsure if the supports are correct – ask someone for help! This is an important part. Plus, if my manager would come to me and ask if I think that the boundary conditions are ok in this report… I would actually appreciate the fact that they cared enough to even wonder about this!
      • You most likely won’t check the loads. But at least check if all of the ones that should be included in the analysis… are included. And if you happen to know a few values of loads – check if those are ok!
      • Take a look at mesh! You won’t test this extensively, but a “nice looking mesh” with quadratic elements is usually decent. As for the mesh size, you can check the simple test I showed above to gauge “by the eye” what a decent mesh looks like!

      And in the end, if you liked this post, you can learn way more by joining my FREE FEA course below!

      Author: Łukasz Skotny Ph.D.

      I have over 10 years of practical FEA experience (I'm running my own Engineering Consultancy), and I've been an academic teacher for a decade. Here, I gladly share my engineering knowledge through courses, and on the blog!

      Read more

      Join my FEA Newsletter

      Get my 1h video Lecture on Nonlinear Material

        Your personal data administrator is Enterfea Łukasz Skotny, Skrzydlata 1/7, 54-129 Wrocław/POLAND, Email. By subscribing to the newsletter that includes marketing messages you consent to your personal data processing in accordance with this privacy policy

        Join the discussion

        Comments (10)

        Grega - 2023-01-06 17:27:10

        Hi Łukasz,

        Great post as usual. I have two questions.
        1) What if you do calculation by standards and you design an uncompetitive product for the market? I came across this at my first job. The company was doing and still is doing big crane calculations amongst other things. Someone is willing to calculate it more on the limit and does a better job than you, that was following the standards.
        2) What if there is a flaw in the standard? I also came across this in the past and it can be a dangerous thing. You are covered, I agree, but still a lot of damage can be done and this goes against engineering ethics.

        Regards to you and keep up the great work with your blog. It is fun to follow it.
        Grega

        Reply
        Łukasz Skotny Ph.D. - 2023-01-08 22:21:57

        Hey Grega!

        Those are the issues I constantly see! And sadly, there is no simple answer to this. Technically, the codes should be verified and "enforced" by some sort of authority that is issuing those. So if everyone "claims" that their product is "by the code", and some companies "lie about it" (regardless if knowingly or not") there should be some sort of a procedure to say "hey, this is not what the specs say", and then that company should have serious trouble for putting something on the market that is not to the standard they declared.

        ... that would be the ideal world at least, and in my knowledge, this almost never happens (!)

        The reality is, that checking if something is "according to the standard" (to a full extent) takes a really good expert in the given field, folks like that usually don't work in government organizations, but have their own companies, or work in the "industries", and often the "checkers" can't really check the nuances, etc. Not to mention that it seems oftentimes that "not too many folks really care". And as such, in several industries (although not in all!) there is a classical wild west! You just do what you feel like since nobody will enforce anything.

        And then, the problem is who will take the "blame" if something really happens! And sadly, this is set up in many countries in such a way, that it's not the manufacturer of the thing (aka the "big company") but the designer (who is very often an "external expert" not an "employee" so he can be put to blame legally without effort). Some people are willing to take such a risk, some are not. This is a philosophical question really.

        The same goes for the codes. Of course, they are not perfect, they are usually too simplistic in too many cases, and some requirements are just dumb. I don't think I have to convince you, that if the code doesn't foresee a problem, and you are aware of it... you still need to "fix it" (although if you would not, and something would happen, it's not obvious if that would be your fault... we are still engineers and the ethics require us to do things the "right way"). It's way more difficult when the code requires something "stupid". Should you follow that rule? Who will be put to blame if this will cause trouble... or something else will cause trouble, but someone will try to put in on that code-avoidance (rightfully or not, doesn't matter)?

        Again - this is a philosophical question! It has very little to do with the technical part of our job really, and in general, it would be wiser to ask a lawyer about stuff like that. Not because the lawyer will tell you what to do (she/he won't) but they will tell you what are the potential problems, so you can make the decision informed about "what is at stake" in this particular problem.

        All the best!
        Ł

        Reply
        Ihor Rokach - 2022-12-08 18:22:04

        Very nice, practical and usefull article.

        One comment. If for some (usually unholy:-)) reason convergence study is not possible, an aposteriory error estimators (always available in all modern FEA programs) should be used. They are quite conservative and allow to select places where "mesh is not small enough" quite simply. IMHO such a plot should be a part of any decent report.

        All the best!

        Reply
        Łukasz Skotny Ph.D. - 2022-12-08 22:35:08

        Hey Ihor!

        Thank you for the cool comment. I'm not sure if such error estimators would work in the case of many analyses (like nonlinear buckling, which I often do), but in some simpler cases, that would be a cool thing. I wonder if Femap has something like that - I will look around in my free time :)

        All the best!
        Ł

        Reply
        Subrahmanyam, from India - 2022-12-08 14:07:41

        Hi Lucaz,
        Very nice article.

        Regarding the mesh size. Can we say that, for the mesh you have shown in this article, nearly 20,000 quad elements will provide accurate results. Where as if we opt for triangular elements, we need nealy 44,000 elements. Is it TRUE?

        I have one doubt. If always quad elements outperform triangular elements. Where do we use triangular elements. Normally softwares (Abaqus I used) use triangular mesh, when we select free mesh. I also read your earlier post on why triangular elements are stiffer.

        Can you please explain, when we need to use specifically triangular elements.

        Reply
        Łukasz Skotny Ph.D. - 2022-12-08 14:49:32

        Thanks Mate, I'm glad that you liked it :)

        Yea, in this particular case, what you wrote is accurate. But please remember that those are nonlinear analyses with very little stress concentrations - so this gives an advantage to TRI elements, who would be worse off in many other applications. I just don't want you to conclude from this, that TRI = 2 * QUAD and all is good... this is not how it works ;)

        As you see, even in such analysis QUAD elements overperform TRI elements. I would never use TRI elements "by choice" (I mean sometimes you need a few in QUAD mesh, I'm referring to model meshed with only TRI elements). There are no advantages at all. Still this is done in many reports to this day, so I posted this example just as a visual reference. I do not advise folks to use "TRI-only" mesh!

        All the best!
        Ł

        Reply
        Ivar KJELBERG - 2022-12-07 18:09:29

        Hi Lukasz,

        Nice Blog, one thing though: your last image series, nice but without any scales it's not that easy to identify a "better / worse" estimate, just as the last "Error %", normally mesh number increase means more precise results, but here the error is relative to what ?

        I fully agree that images without explanations is not enough in a report, number are essentials, and checks: if you apply loads (the usual case :) you should also provide reaction forces, or total reaction forces that should tend towards "zero". I prefer the former, as the latter could cancel out by error somewhere in the model.
        Now for you, with all your shell work this might be enough, for us doing heavy "multi-physics" one should be careful too, to check that the equivalent "reaction forces" are tested out for ALL physics, that power in = power out for thermal, fluid in is coming out, for CFD ... All conservation laws should be scanned in the report.

        Thanks again for interesting readings
        Sincerely
        Ivar

        Reply
        Łukasz Skotny Ph.D. - 2022-12-07 19:54:24

        Hey Ivar!
        Thank you for the comment!
        I may have been a bit too quick with the description, but all you need is actually there. The picture doesn't need a scale - it's just a stress state under the same load for a visible mesh size - just so you get a feeling how the outcomes look like. Realistically the scale is RED = 235MPa (which is yield stress), and the others change toward zero... although that wouldn't change the fact that it's the outcome for the same conditions... the only difference is the mesh, so comparing stresses here wouldn't be that productive really.
        As for the error, this is an error related to the point where the mesh size doesn't impact the outcomes anymore for QUAD elements. So I called the "converged mesh" outcome in QUAD elements correct, and the error is in relation to that (and I must admit I don't really like the term "converged mesh" but this is beyond the point).

        Ach yes, I do work in structural design, but of course if you would broaden the application there would be presumably much more things you should pay attention too :)

        All the best!
        Ł

        Reply
        Jo Vankan - 2022-12-06 11:07:22

        Perhaps instead of using the word "code" for "standard" use the word "norm", like in DIN (Deutsche Industrie Norm) because the word "code" is used in relation with software, like ABACUS "code".

        Reply
        Łukasz Skotny Ph.D. - 2022-12-07 10:37:24

        Hey Jo!

        This is such a difficult topic. I don't think there is a good way to translate this - after all, even the Eurocodes use the "code" not the "norm", although I would like Euronorms better for precisely the reason that you've mentioned. I think that in US such documents are referenced as "standards" but ever ASME on official order has the text "codes and standards".

        I can only hope that this is clear for the reader what I'm writing about, especially since I've posted some examples of the "codes", although I admit that this is a very tricky issue!

        All the best!
        Ł

        Reply

        Sign up for my FEA Newsletter!

        Each Tuesday you will get awesome FEA Content directly yo your email!

          Your personal data administrator is Enterfea Łukasz Skotny, Skrzydlata 1/7, 54-129 Wrocław/POLAND, Email. By subscribing to the newsletter that includes marketing messages you consent to your personal data processing in accordance with this privacy policy