General -> Product URL property sometimes not saved

A forum to discuss the implementation of a good Materials system in FreeCAD
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
yorik
Founder
Posts: 13640
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: General -> Product URL property sometimes not saved

Post by yorik »

For me a "price" field is useful, because something we do quite often in the building industry is price estimation for a project. You basically make a spreadsheet where you count how much brick wall, how much concrete beams, etc... there is in a project, and give a price to each. The best way to achieve this is to store a price value in materials. Of course prices change all the time, and from place to place, so it's not something one would store in a material card. But I still think it's important for the field to exist.
Jee-Bee wrote: Thu Feb 14, 2019 3:35 pm I proposed once (that's what my memory says at least couldn't find it back) to remove the units(from objects) at all. The only place where the units are handled are the unit preferences.
Ideally indeed, this should be totally transparent, and values be stored in any unit in the file, and shown to you in the unit of your choice in the GUI. I guess the materials UI just needs some more polishing. There are not many people using it, so few people actually work on it (Bernd doing almost all the work nowadays, I'll get back to it Bernd, I swear! ;) )

When possible, we always save things indeed as floats with no unit (in millimeters, basically), but since the units system can convert with ease, this is not totally necessary. Plus, since values are saved as strings in materials, you cannot store values as a real float anyway...
User avatar
bernd
Veteran
Posts: 12849
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland
Contact:

Re: General -> Product URL property sometimes not saved

Post by bernd »

Some month ago I was brave and implemented a button in FEM to edit the material parameter by the material editor. It was just a matter of time a new user would appear, start to use the material editor and complains about problems. Exactly this happened ... At the moment I try to fix as much as possible for the release ... :)
User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

Re: General -> Product URL property sometimes not saved

Post by uwestoehr »

yorik wrote: Fri Feb 15, 2019 12:16 pm For me a "price" field is useful, because something we do quite often in the building industry is price estimation for a project. You basically make a spreadsheet where you count how much brick wall, how much concrete beams, etc... there is in a project, and give a price to each.
I wonder that this doesn't cause serious problems for you. In my experience the material "brick" can cost 10 Cents per brick part or 2 $, depending on the shape quality, pore density, color, supplier and so on. I just had a look in my lunch break in the neighboring garden center.
The more I think about it the less I see why a cost for a material would be sensible. Take for example wood, it makes a huge difference how the wood is shaped, what kind of wood, how much you buy at one, if you can buy it directly from a state forest or from a company etc.. The differences are several 100%.

I thought the material editor is in FC because of
- necessary to perform FEM analysis
- to apply a default surface shade and color for display and ray tracing
- to be able to specify the material in a technical drawing
- what do I miss?

I am pretty sure that every company has its own price handling system and I think this is for good reason.
If you see reliable applications, then of course keep the price. It would then be useful that the use cases are documented in the Wiki.

Btw. I see that most FEM Wiki pages are empty. I almost finished the description for a2plus and when I find time I will document FEM. But be warned - writing documentation leads to many bug reports ;-)
User avatar
bernd
Veteran
Posts: 12849
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland
Contact:

Re: General -> Product URL property sometimes not saved

Post by bernd »

some one writing FEM documentation would be awesome because it is something I surely should do more but just ignores mostly.

Yeah and even better is it would make FEMore robust!

Go ahead! Like in materials I will give my best in fuxing the bugs.
User avatar
bernd
Veteran
Posts: 12849
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland
Contact:

Re: General -> Product URL property sometimes not saved

Post by bernd »

I would vote for keeping price attributes, but I would not fill them because the value leads to disscusions not the attribute itself. As uwe said everyone has its own price.

BTW started to implement something for price calculation, but especially for concrete work in switzerland.
User avatar
yorik
Founder
Posts: 13640
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: General -> Product URL property sometimes not saved

Post by yorik »

uwestoehr wrote: Fri Feb 15, 2019 4:40 pm I wonder that this doesn't cause serious problems for you. In my experience the material "brick" can cost 10 Cents per brick part or 2 $, depending on the shape quality, pore density, color, supplier and so on. I just had a look in my lunch break in the neighboring garden center.
Of course. Therefore we don't name these just "brick wall" but something like "wall made of bricks of type XXX, color YYY, manufacturer ZZZ installed in such way with such quantity of mortar made of XXX of sand and YYY of cement, reinforced with on iron bar of diameter XXX at every YYY row" :) Then, given the place you are and the average salaries and how much workman/hour to build a brick wall (all data usually available somewhere), you can get a pretty correct estimation.

Of course, not for a single brick wall. The estimation error margin could represent a big part of the wall cost. But for a larger building, it becomes quite safe.
User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

Re: General -> Product URL property sometimes not saved

Post by uwestoehr »

yorik wrote: Sat Feb 16, 2019 9:57 pm Of course. Therefore we don't name these just "brick wall" but something like "wall made of bricks of type XXX, color YYY, manufacturer ZZZ installed in such way with such quantity of mortar made of XXX of sand and YYY of cement, reinforced with on iron bar of diameter XXX at every YYY row" :) Then, given the place you are and the average salaries and how much workman/hour to build a brick wall (all data usually available somewhere), you can get a pretty correct estimation.
Interesting approach. So you as an architect set up a material card for every different available brick type?
As an engineer I need the physical parameters of a material because first I need to check what material would do the job. Then if we found one, we start calculating prices. Therefore we don't set up a material card for every available type of e.g. AISI 316L stainless steel, but only one card for it.
User avatar
bernd
Veteran
Posts: 12849
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland
Contact:

Re: General -> Product URL property sometimes not saved

Post by bernd »

Here we do not have a smart solution. For example an architect would use one card for concrete C25/30 and C30/37 since they do not differ for him, but a structural engineer would use two cards because of different compressive strength.

What I want to show is there are examples where one would make one card and the other would make two cards. We gone find much more examples here.

May be a tree structure could help, but I assume even that does not fit. There are just to many material attributes around.

The news is even the big ones have not solved this yet.
User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

Re: General -> Product URL property sometimes not saved

Post by uwestoehr »

bernd wrote: Sun Feb 17, 2019 8:37 am Here we do not have a smart solution. For example an architect would use one card for concrete C25/30 and C30/37 since they do not differ for him, but a structural engineer would use two cards because of different compressive strength.
I understand. So let's keep the price property then. When I write in the Wiki I will mention that people should not rely on this but use it only for estimations (not that users try to sue us ;) )
User avatar
yorik
Founder
Posts: 13640
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: General -> Product URL property sometimes not saved

Post by yorik »

Indeed, we should definitely not add a price to our default cards :)
bernd wrote: Sun Feb 17, 2019 8:37 am May be a tree structure could help, but I assume even that does not fit. There are just to many material attributes around.
Yes, I definitely see this as a long process. You start your project with only a few materials: concrete, brick, wood,... Then during the project development, you "subdivide" into more precise ones. There is a "Father" attribute in materials, that is very good to create a hierarchy. The Arch materials show as a tree if they have their Father property set (still some bugs, I didn't use it enough yet)

This is still a bit clumsy to set up and use, but I think it's a good way to go...
Post Reply