Light bulb moment! That's why I don't like Engineers Australia's activities. The institution of engineers Australia (IEAust), basically became a full commercial trading company: Engineers Australia. It is basically in the business of selling post nominal detritus.
The IEAust is not a learned society. A learned society is curator, guardian and disseminator of learning.
The IEAust rightly recognised that the B.Eng was not adequate indicator of competence, it also recognised that MIEAust had lost its reliability as an indicator of competence.: further more few people were interested in acquiring. The problem was that many people previously held graduate status for most of their careers, especially those who worked on construction sites. The contention was that those who worked in a design office could easily get site experience, whilst those who worked on site had problems gaining design office experience. Further the contention was that the site experience that those in design office acquired was worthless compared to that acquired by those who worked on site. The problem: a failure to recognise major areas of practice and the specialised knowledge required for these areas. Therefore no one has any real certainty as to whether any individual as the necessary skills for a given job. Jobs are not really civil engineering or mechanical engineering, or any other major engineering discipline.
Rather than tackle the problem, Engineers Australia dreamed up a long string of post nominal detritus: MIEAust CPEng NPER : all totally worthless and meaningless and fails to resolve the original problem. Additionally they absorbed the institute of engineering associates, and introduced the concept of engineering technologist. The technical engineering team of knowledge workers thus expanded from 2 occupational classes to 3. Engineers Australia primarily promotes the occupation of professional engineer and gives scant regard to the rest of the team.
It seems they are expecting the Big Bang or something to give spontaneous existence to engineering technologists, and achieve critical mass or something and form their own group and direct their own occupation. Its a totally stupid idea.
The specification for the engineering team states that there is overlap between the knowledge base of the three occupations. There is not equality, there is not hierarchy. From the specification Engineers do not know anything that engineering associates know, there is no overlap with their knowledge base. Which seems a stupid definition: but that's what those all knowledgeable MIEAust/FIEAust's dreamed up. Having dreamed this up however, they continue to exercise an arrogance that they know more than anybody else, that they are the best, and seemingly the only people society needs. Further more the industrial relations system is set up such that get higher wages based on education and potential of that education, not based on actual contribution to an organisation. The result: get a B.Eng become an Engineer, get higher wages. More nonsense.
Yes there is a shortage of engineers in terms of the traditional meaning of someone pushing forward the frontiers of technology. Yes there is a shortage of competent managers and technical designers. This does not however mean we should set a propaganda machine in motion and churn out people with degrees.
Graduates are not engineers, nor graduate engineers or graduate anything else, they are simply graduates with an education which may or may not have been any value. They are at best technicians part conversant in the use of a variety of mathematical tools and techniques: but not otherwise highly proficient in the use of these tools, nor highly conversant in any given technology to which these tools need to be applied. Industry cannot be relied on to provide the necessary training: more over such on the job training can be an unwarranted hindrance and expense to getting on with the job at hand.
However, it is not the task of an engineer to assess the suitability of a beam, a building or a bridge, or any other established technology. The role of engineer is at the frontiers of science and technology: technologies for which we do not yet have any established body of technical science.
Where we do have a body of established knowledge we can train Associate Technologists (my preferred name for the engineering associates).
No need to bring in any silly post nominal's, no need to split one group of people with a B.Eng from others with a B.Eng. Just a need to pay attention to the design and specification of the engineering team and role of each player. Also a need for many of the professional engineers to stop being derogatory about the competence of engineering associates: because to put it bluntly a large number of MIEAust's are not actually smart enough to know their own limitations and neither competent enough to do the research to expand their knowledge. Why would they? They think they know it all, already.
I attended an introductory chartered workshop a few years back, it put me off the whole idea, just reinforced the view that its all nonsense. It was a mixed group, one of the engineering associates asked if they needed to be able to design a concrete column. The response was an uncertain maybe.
There is no uncertainty about it. The academic studies of an engineering associate covers the design of reinforced concrete beams, columns and slabs. If they work in the structural area then they are expected to design reinforced concrete. Engineering associates are not drafters nor trade technicians. Those engineering associates are spending their own time programming AutoCAD because their jobs are boring them to death, their education is not being used.
The task of Engineers Australia wasn't to cause division and confusion, but to clearly separate education from industry. Just because a person has a B.Eng does not mean that they will ever achieve the on the job training and experience to ever become an MIEAust. But a B.Eng OMIEAust clearly has more potential than a Assoc.Dip OMIEAust. Thus OMIEAust is a first stage stepping stone, not something to be sniffed at with disdain. Further more such stepping stones through OMIEAust to TMIEAust should be the only way to get to MIEAust. If we are to consider there is an hierarchy, then the MIEAust's should have a knowledge base which fully over laps with the lower grades. We want the people pushing the frontiers to be fully conversant with the established technologies and the accepted procedures for proof of concept and evidence of suitability, before they start re-inventing the wheel and place society and the whole planet at risk.
In 2 years we can train engineering associates, and for them 3 years of experience after graduation is probably appropriate for them to become OMIEAust and then CEngO: if really need such post nominal detritus. Similarly in 3 years those with a B.Eng also become OMIEAust. Are they going to choose to do this. No they are not, they will only do this if it is the mandatory stepping stone towards MIEAust. Further they will only consider doing so, if the legislation requires registration on the national engineering associates register( NEAR) in a specific area of practice for submission of engineering work to regulatory authorities.
No legislation should restrict practice or restrict the supply of services. The legislation should merely identify that regulatory authorities do not have time to waste with incomplete submissions and therefore will only accept submissions which have been at least reviewed and endorsed by someone on a national register: depending on the complexity it could reference NEAR, NETR, NPER. But the requirement should be that no higher registration than NEAR is required for 80% of the work. If there is any apparent reduction in this percentage, then the requirements for registration on NEAR should increase, and cascade through to all the other registers. However I contend that very little requires more than 2 years of tertiary education, and that anything that pushes up to requiring NETR in fact requires additional areas of practice to be defined on NEAR and appropriate two year qualifications developed to produce specialisation in this area.
I reiterate, no engineering associate should be educated in the broad area of an engineering discipline, they are to be educated in a specific area of practice: such as storm water drainage, or structural design. However would not expect them to design massive dams, railway bridges or multi-storey buildings greater than 6 storeys high. (3m per storey x 6 storeys = 18m potential supply of steel, without a splice if you're lucky, 12m is more common.)
This is not to say they are not capable, they are most certainly capable of contributing to a significant extent. The issue is that persons with far greater breadth of knowledge should be supervising the design function for more complex technologies. These people with greater breadth of knowledge should also have greater breadth of experience.
I have heard some professional engineers talk about throwing graduates in the deep end. This is all very good as long as it does not cause unwarranted expense to the client or hazard to factory and construction workers, nor create hazard to the community. The deep end is not that of a professional engineer: the deep end for a graduate is that for an engineering associate.
An engineering associate can take project from concept to implementation, the issue is that these projects have little uncertainty and little risk. All the technologies and procedures are established, including those for assessing suitability of purpose and proof of concept. There is little unexpected to turn up.
The unexpected always turns up: and that's because no individual can know everything and few are ever given all the time really required to review all that is needed. So there is always some issue to be resolved working fast on your feet in real time. Further there is hopefully someone who can assist to get out off the trouble because they have been there before and/or know the solution. The alternative is that there is the ideal and there is reality, and no need to get pedantic about process if it doesn't really make much difference: hopefully get it right on the next one. Because until get it right on the simple projects, the individual is not going to be moved to more complex projects, more to the point the business is likely to avoid complex projects, if the simple and predictable keep turning into nightmares.
There are a multitude of small businesses which need to be employing engineering associates on staff so that engineers can get on with the more complex stuff.
In the larger organisations, engineering associates can be taken off drawing boards and allowed to put their education to work typically doing what engineers are currently doing. The engineers can then be freed to put their actual education to work. {Ah! But they want the status without actually using their degree.}
Drafters can be more readily trained. Also people have not necessarily chosen Associate Degrees due to lack of ability, its more likely lack of funds: the need to expend the minimum amount of time to get a ticket to employment, and start earning income. So if got engineering associates on staff, push them, give them opportunity to prove themselves, and assist the best to get higher education., and move up through technologist to engineer. Of course a company has to be doing more than the routine to unleash the potential of graduate engineers.
Also to put it bluntly, in the main industry is better served by people with multiple associate degrees than persons having a single bachelor degree, masters degrees are also of limited value. Its not depth that is sought, it is breadth, and adaptability. Also 2 people with associate degrees can accomplish far more than one person with a bachelor degree in a given time frame on the routine tasks that are typically carried out.
{NB: The problem is that at present too many academic programmes are biased towards the breadth of the engineering disciplines, rather specialist areas of practice. The result is no one is job ready. Engineering Associates should be job ready, only need a few days of supervision to get started, and be up to speed after 12 months on the job. Not interested in what happens. This requirement is the specification, if its not happening then the education needs changing.}
A journal on everything technological and everything to do with structure: from building structures, to organisation structures, politics, education, and business. If it has structure I will essay it, if it ought to have structure I will essay it. If it don't have structure and it is chaos, I essay that too!
Monday, October 28, 2013
Sunday, October 27, 2013
More Irritation with Engineers Australia and APESMA
I thought I had shut down all input from social networks associated with these groups, so that I wouldn't be distracted by their nonsense, but seems I was wrong: some leaked through.
It seems APESMA, the association of professional engineers scientists and managers Australia has created new internal groupings or something, and so Professional Engineers Australia has emerged.
I guess they didn't like resurrecting the original name which was something like: APES. A name which some probably think is an apt description of engineers. It certainly reflects my understanding of the letter 'P' in CP.Eng. Nearly 5 years they took to dream this post nominal detritus up to improve status: not sure how capitalist profiteer, or cretinous primate, improves status. See once something is released to the market it takes on a whole new live of its own: and since engineers are seen as ignorant of the environment and the consequences of the technologies they release, it is clear that any post nominal dreamed up needs to be such that it does not provide an easy hook into reinforcing the communities negative views. It should be noted I only listed the relatively polite possibilities for CP, I'm sure people can find more interesting expletives to use.
However, back to the issue, I do not see any value in creating these separatist elitist clique's.
Further the issue of importance is that Engineers Australia sought to redesign the industrial environment, and poorly executed its implementation. It introduced the concept of engineering technologists, without creating an industrial award for such. It ignored the technical officers awards and renamed engineering associates to engineering officers. It further ignored the technical officers awards which placed engineering technicians subordinate to engineering associates and equated engineering associates to WFEO engineering technicians. With the federal system, most of the state awards have been scrapped, and currently there appears to be only one federal award and that is for technical professionals: which doesn't cover the full technical team.
Further in the design of this new industrial environment, it is inappropriate to hold the new members of the engineering team as responsible for creating their own little groups and promoting their occupation. It is meant to be an engineering team, and each member of the team has an identifiable skill set not held by other members. Engineering Associates form the solid foundation on which the pinnacle stands firm, they are essential. The professional engineers and engineering technologists are not essential.
The engineering associates deal with the firmly established technologies, for which the technical science is well established and the risk and uncertainty is extremely low: and they are supposed to be educated in specific areas of practice not broad engineering disciplines. Engineering associates are responsible for the technologies we have and are dependent upon, their body of knowledge defines the frontier of science and technology. Just because a technology was originally designed by an engineer, does not mean that an engineer is needed to redesign apply and adapt that technology.
By promoting occupational cliques and professional elitism, we are eroding the foundation. Further more the resulting professionals are something far less than the learned elite they contend to be.
It also causes industrial relations problems. If work is well within the capabilities of an engineering associate but an engineer typically does the work, then to pass the work over to the engineering associate raises the contention that the engineering associate is doing the work of an engineer and therefore should be paid as such.
On the other hand if the work is with in the capabilities of an engineering associate then the engineer doing the work should be paid as an engineering associate not an engineer, ignoring the potential the B.Eng provides and pay according to their actual contribution not according to their education. This industrial relations system also hampers developing new technologies and then handing over to engineering associates once the technology has been established.
Once a technology is released to the market it will be put to uses far beyond the intents of the designers, and likely have impacts beyond their imaginations. Engineers Australia has basically demonstrated poor planning, design and management skills with respect to the industrial products it is trying market. These human cogs it has defined don't really fit anywhere. Industry is basically being forced to buy what is being supplied rather than what it really needs. But then again it could design and make what it needs: or is there something preventing them from doing so? I'd contend the professions are an obstructive obstacle.
I contend that Engineers Australia is attempting to float a pinnacle in fresh air, rather than stand it on a firm foundation. The contention has been held that some of the big mining and infrastructure projects have failed to launch due to a shortage of engineers.
My contention is they failed to launch due to having eroded the foundation of the engineering team: namely the trades people, the drafters and the engineering associates. These people form the army which makes things happen, engineers have the vision to give them direction and put them to work.
I contend we are creating a society which is top heavy. We should stop promoting professional engineer to school leavers, and instead promote engineering, and get them in at the ground floor. With plenty of opportunity for the best to step up the ranks towards professional engineer.
At present the professional engineers, the CP.Eng's are less than the learned people they contend to be.
That has a two fold effect. One is that industry has no faith in CP.Eng as a reliable indicator of technical competence, and therefore will not select employees on the basis of such accreditation over and above any other qualifications. Secondly persons not having CP.Eng credentials, don't see those with CP.Eng as being competent, and therefore see no reason to join such class of individuals.
In fact it can work the other way round. Clients themselves having got some rubbish from a CP.Eng go looking for a real engineer: that usually means older engineers and/or engineers with overseas qualifications. People who actually gained experience working on serious projects, under the supervision of a properly qualified individual, and who then went through some relevant qualification process for their discipline. The CP.Eng credential is based on some generic rubbish, and is an unreliable test of technical competence: it is based on far too great an assumption that the competence comes from the B.Eng: the required technical competence never has come from such degree. Some CP.Eng's are competent, the issue is that its an unreliable indicator: as we do not know what they are competent in, nor what they are deficient in.
For example a lot of the civil/structural engineers operating in the area of manufactured structural products are a public menace. Besides lacking adequate knowledge of structures, they also lack knowledge of industrial product design. The result is poor service to the manufacturer/suppliers of the structural products and poor service to the greater community. Those carrying out certification work for the regulating authorities are no better.
A lot of the work which passes through the office is well within the capabilities of engineering associates, it is dull for engineering technologists, the work is flowing in because people think they need an engineer. This work should be flowing to engineering associates in the first place.
The regulators should stop refer to the need for engineering and the need for engineers reports. The requirements of the system are adequate evidence-of-suitability, and often the engineers are not capable of supplying adequate evidence: as they lack adequate knowledge of the technology they are supposed to be assessing and otherwise fail to properly research such established technology, or otherwise don't have the time.
Established technology is the realm of engineering associates, or as I prefer Associate Technologists. Forget about recent years in which engineers have been relegated to being the tools of regulators. The proper role of an engineer is pushing forward the frontiers of science and technology. Their education is for such purpose and they lack adequate knowledge of the established technologies, and industry is unreliable as a trainer.
The Associate Technologist is meant to be educated in the specific area of practice not a broad engineering discipline. Their task is to maintain the technological base of our industrial society. Buildings shouldn't fall down, bridges shouldn't collapse, machines shouldn't blow up. All of this is established technology.
After an engineer as originated something, the ingenious leap of logic is no longer necessary. A new generation of technologists and Associate Technologists can be trained to apply and implement such new technology.
We are pushing the elitism of the professional engineer and failing to train the people we really need. Lets make sure we build and sustain an army of competent Associate Technologists before we push the elitism of professional engineer.
It seems APESMA, the association of professional engineers scientists and managers Australia has created new internal groupings or something, and so Professional Engineers Australia has emerged.
I guess they didn't like resurrecting the original name which was something like: APES. A name which some probably think is an apt description of engineers. It certainly reflects my understanding of the letter 'P' in CP.Eng. Nearly 5 years they took to dream this post nominal detritus up to improve status: not sure how capitalist profiteer, or cretinous primate, improves status. See once something is released to the market it takes on a whole new live of its own: and since engineers are seen as ignorant of the environment and the consequences of the technologies they release, it is clear that any post nominal dreamed up needs to be such that it does not provide an easy hook into reinforcing the communities negative views. It should be noted I only listed the relatively polite possibilities for CP, I'm sure people can find more interesting expletives to use.
However, back to the issue, I do not see any value in creating these separatist elitist clique's.
Further the issue of importance is that Engineers Australia sought to redesign the industrial environment, and poorly executed its implementation. It introduced the concept of engineering technologists, without creating an industrial award for such. It ignored the technical officers awards and renamed engineering associates to engineering officers. It further ignored the technical officers awards which placed engineering technicians subordinate to engineering associates and equated engineering associates to WFEO engineering technicians. With the federal system, most of the state awards have been scrapped, and currently there appears to be only one federal award and that is for technical professionals: which doesn't cover the full technical team.
Further in the design of this new industrial environment, it is inappropriate to hold the new members of the engineering team as responsible for creating their own little groups and promoting their occupation. It is meant to be an engineering team, and each member of the team has an identifiable skill set not held by other members. Engineering Associates form the solid foundation on which the pinnacle stands firm, they are essential. The professional engineers and engineering technologists are not essential.
The engineering associates deal with the firmly established technologies, for which the technical science is well established and the risk and uncertainty is extremely low: and they are supposed to be educated in specific areas of practice not broad engineering disciplines. Engineering associates are responsible for the technologies we have and are dependent upon, their body of knowledge defines the frontier of science and technology. Just because a technology was originally designed by an engineer, does not mean that an engineer is needed to redesign apply and adapt that technology.
By promoting occupational cliques and professional elitism, we are eroding the foundation. Further more the resulting professionals are something far less than the learned elite they contend to be.
It also causes industrial relations problems. If work is well within the capabilities of an engineering associate but an engineer typically does the work, then to pass the work over to the engineering associate raises the contention that the engineering associate is doing the work of an engineer and therefore should be paid as such.
On the other hand if the work is with in the capabilities of an engineering associate then the engineer doing the work should be paid as an engineering associate not an engineer, ignoring the potential the B.Eng provides and pay according to their actual contribution not according to their education. This industrial relations system also hampers developing new technologies and then handing over to engineering associates once the technology has been established.
Once a technology is released to the market it will be put to uses far beyond the intents of the designers, and likely have impacts beyond their imaginations. Engineers Australia has basically demonstrated poor planning, design and management skills with respect to the industrial products it is trying market. These human cogs it has defined don't really fit anywhere. Industry is basically being forced to buy what is being supplied rather than what it really needs. But then again it could design and make what it needs: or is there something preventing them from doing so? I'd contend the professions are an obstructive obstacle.
I contend that Engineers Australia is attempting to float a pinnacle in fresh air, rather than stand it on a firm foundation. The contention has been held that some of the big mining and infrastructure projects have failed to launch due to a shortage of engineers.
My contention is they failed to launch due to having eroded the foundation of the engineering team: namely the trades people, the drafters and the engineering associates. These people form the army which makes things happen, engineers have the vision to give them direction and put them to work.
I contend we are creating a society which is top heavy. We should stop promoting professional engineer to school leavers, and instead promote engineering, and get them in at the ground floor. With plenty of opportunity for the best to step up the ranks towards professional engineer.
At present the professional engineers, the CP.Eng's are less than the learned people they contend to be.
That has a two fold effect. One is that industry has no faith in CP.Eng as a reliable indicator of technical competence, and therefore will not select employees on the basis of such accreditation over and above any other qualifications. Secondly persons not having CP.Eng credentials, don't see those with CP.Eng as being competent, and therefore see no reason to join such class of individuals.
In fact it can work the other way round. Clients themselves having got some rubbish from a CP.Eng go looking for a real engineer: that usually means older engineers and/or engineers with overseas qualifications. People who actually gained experience working on serious projects, under the supervision of a properly qualified individual, and who then went through some relevant qualification process for their discipline. The CP.Eng credential is based on some generic rubbish, and is an unreliable test of technical competence: it is based on far too great an assumption that the competence comes from the B.Eng: the required technical competence never has come from such degree. Some CP.Eng's are competent, the issue is that its an unreliable indicator: as we do not know what they are competent in, nor what they are deficient in.
For example a lot of the civil/structural engineers operating in the area of manufactured structural products are a public menace. Besides lacking adequate knowledge of structures, they also lack knowledge of industrial product design. The result is poor service to the manufacturer/suppliers of the structural products and poor service to the greater community. Those carrying out certification work for the regulating authorities are no better.
A lot of the work which passes through the office is well within the capabilities of engineering associates, it is dull for engineering technologists, the work is flowing in because people think they need an engineer. This work should be flowing to engineering associates in the first place.
The regulators should stop refer to the need for engineering and the need for engineers reports. The requirements of the system are adequate evidence-of-suitability, and often the engineers are not capable of supplying adequate evidence: as they lack adequate knowledge of the technology they are supposed to be assessing and otherwise fail to properly research such established technology, or otherwise don't have the time.
Established technology is the realm of engineering associates, or as I prefer Associate Technologists. Forget about recent years in which engineers have been relegated to being the tools of regulators. The proper role of an engineer is pushing forward the frontiers of science and technology. Their education is for such purpose and they lack adequate knowledge of the established technologies, and industry is unreliable as a trainer.
The Associate Technologist is meant to be educated in the specific area of practice not a broad engineering discipline. Their task is to maintain the technological base of our industrial society. Buildings shouldn't fall down, bridges shouldn't collapse, machines shouldn't blow up. All of this is established technology.
After an engineer as originated something, the ingenious leap of logic is no longer necessary. A new generation of technologists and Associate Technologists can be trained to apply and implement such new technology.
We are pushing the elitism of the professional engineer and failing to train the people we really need. Lets make sure we build and sustain an army of competent Associate Technologists before we push the elitism of professional engineer.
Wednesday, October 16, 2013
Data file formats for interchanging and sharing data from user applications
When I wrote my soil heave program I based its data file format on what I had otherwise learnt about DXF files. I did this to keep the reading of the data simple, as I hadn't otherwise written any code to process a comma delimited file (.cdf), and I had both numbers and text and all kinds of problems were encountered if text and numbers are on the same line and use the standard input/output routines with languages like Pascal and C.
The format of the data file adopted therefore comprises of a line with the tag name followed by another line with the tag value. However I didn't include all the complicated nesting and sections typically found in a DXF file. However the soil heave program is based on multiple soil cores being split into multiple strata, and this introduced some inconsistency into reading and writing the data format. Whilst the Core tag is followed by a count of the reference number of the core, the end core tag has no tag value following it. Similarly the end of file tag (EOF) also has no tag value following it. But for simple data sets, this poses no real problem for reading and writing the file. For more complex data sets however, a more consistent data format is required, with a simple parser which can be called repetitively.
When I recently came to revisit the data file format for exporting data from my spreadsheets, I discovered XML files.
No need to re-invent the wheel, nor particularly any need to write a file parser as such, such file readers are built into various programming environments. The only task is having got the data, to sort it and assign to appropriate variables inside the user application: well programming wise. The bigger task is to decide on the format of the data.
I realise that MS Excel exports data to an XML file, newer may even use such as the default format, however that contains more information than I am interested in, and is about data defining a spreadsheet, not the structure of the data stored in the spreadsheet.
So at present I have wrapped the whole data set in the tag, namely its my data, formatted my way. Then I have divided the data into parameters and variables. Parameters are named ranges in an Excel spreadsheet which contain a simple value and have no formula. Variables are named ranges which contain formula. So parameters are wrapped in tags, and variables are wrapped in tags. Nested inside these tags, are tags for the name of the range, and tags for the stored value.
Whilst writing this code in MS Excel/vba I also had problems dealing with Unicode characters, as Excel cells contained values which disappeared when written to a text file using the ordinary print functions. Having got the data into a text file also had problems reading them back in. But resolved the problems using the VBScript file system objects for reading and writing files.
The other problem encountered in the export of data to an XML file was that not all the named ranges were simple scalar values, some were lists and tables. So also added additional tags, if a range only lay on a single row or column, then the range classified as a list and tagged
An alternative format, or schema, I considered was to consider using the MS Excel range name as the XML tag, and then wrapping the value in these tags. The problem I had with that approach is that it is less generic. Whilst it may be the more valid way of defining the fields for a database in XML, it doesn't match what I already have in MS Excel and MS Access. In Excel all my variables are typically defined on one worksheet which is compatible with import into an MS Access table. In this way I can add new variables as I wish if I don't have need for a variable or more to the point if a program doesn't know what to do with the variable it can be ignored.
Whilst XML provides flexibility, and can easily write a new variable as a new XML tag, the problem is reading the XML file and then knowing what to do next with the data which comes after the tag. In effect an XML data file has to be parsed twice when using XML objects. The first level of parsing is to grab all the XML tags, any contained attributes, and then the data contained between the tags. The second level of parsing is determining what to do with the tags and data with respect to some specific application.
A book database with a fixed data structure is relatively simple: just read the XML file, and then permit searching and listing information about the list of books contained in the database. Throw variable data structures into the database, then need different processors for each data set found. For example with respect to CAD data, may have a circle and a line. A data structure for a circle contains say the diameter of the circle and may be its insertion point. The data structure for a line contains say the coordinates of the two ends of the line. Displaying a line on the screen is different than displaying a circle. So as the program works its way through all the data, it calls different commands to execute based on the data encountered at any given point in reading the data.
At the time of this experimenting, it seemed to me that if the variable name was used as a tag, then when read a variable unknown to the program, it would loose synchronisation with reading the rest of the file. {This may have had more to do with my writing a parser from scratch rather than using XML reader objects. Which is also why I didn't use parameter and variable as tag attributes. Something like isparameter=1}
If can read all the data into a XML tree object, then if traverse the tree and find a tag do not know, then can ignore the entire branch starting from that node. But if cannot read the entire data into an XML tree object, then seems to me, need to decide what to do as progress through the data: since cannot ignore an entire branch until identified the branch: found the end tag.
I don't know really, probably need to experiment with both approaches. Another approach adopted by some software is to use the tag attributes to contain data. This approach I don't like as it confuses things. Data is supposed to be between the tags, and the tags can contain attributes descriptive of the data. However storing data in the attributes can make the data file more compact and easier to read. For example, the definition of a node could be as follows:
Parameters are input variables and can be changed, whilst those items I have named variables are dependent variables their value is dependent on the value of input parameters, and the process which relates the input to output. Change the process which relates the parameter to variable and change the output of the program. For example height and span could relate to a gable roof building or a skillion roof building or for that matter a balustrade. Thus two basic parameters can get transformed into a variety of structural forms. Further I can define a building as a series of bents. Each bent comprises one column and one rafter. To define a monoslope roof from bents, then the rafter would be split at mid point or any other convenient location along the rafter. Alternatively permit the bent to only comprise of a column. Any case the parameters height and span could occur multiple times and their meaning would vary depending on the object in which they are contained.
Say I throw another parameter in such as eavesHeight, then could have either of the following:
Method 1:
I guess from my viewpoint, when I set up my spreadsheets I didn't know what the input parameters were. I simply worked through the calculations and unprotected certain values as parameters. I then shifted the input of these values to a worksheet used for input values. In Quatro Pro it was necessary to have all the input values to a dialogue box in a continuous block, and since I also wanted the data to be compatible with Paradox it also fell into place as one or more tables. Without the dialogue boxes it also seemed appropriate to collect similar data in sets, with one worksheet per set of data. So ended up with multiple tabbed sheets each of which was compatible with export to a database. When moved over to MS Excel and MS Access, the concept was maintained, even though can feed data from any where into a dialogue box.
So the tables or worksheets are not just a convenient place for named cells/ranges, its not just a simple matter of getting a value for a variable. The tables are defining the parameters which define the object which the spreadsheet is used to design.
So that the list of parameters and their names are just as important as the values of the parameters. Still doesn't give me a reason for putting the names between the XML tags rather than making them the XML tags. {I guess my reasoning is the parameters are data describing an object, change the object the parameters change. Therefore I have added another level of abstraction for the data, which may not be necessary.}
Any case that's the idea at present, if there is a named range in MS Excel then its value is exported to an XML file. If the data in an XML file is a parameter then it can be imported into an MS Excel worksheet. This way large spreadsheets do not have to be stored for individual projects, the MS Excel workbook just gets used as an application, and the required data is stored in simple XML files. This data can also be shared across different Excel workbooks which fulfil different functions. So all the data for a project can be stored in a central XML file, and used by a variety of applications. Each application just reads and writes the data it needs without messing up the data file for other applications.
Of course I could just use a simple Excel spreadsheet to get data to and from complex Excel workbooks, but that supposes Excel is available. Further not every suitable application will be built using Excel, plus XML is also useful for web based data storage. Which means faster development of a web based application at future date.
Looks like I need to figure out how to display the XML brackets. < and > is not working, and neither does using the actual characters. Take that back, it doesn't display correctly in compose. Now for the other problem: none of the sites I found providing a solution, actually explain properly what is required because the codes they recommend are translated and therefore see the results not the recommended codes. The results and codes are:
< is displayed by <
> is displayed by >
The format of the data file adopted therefore comprises of a line with the tag name followed by another line with the tag value. However I didn't include all the complicated nesting and sections typically found in a DXF file. However the soil heave program is based on multiple soil cores being split into multiple strata, and this introduced some inconsistency into reading and writing the data format. Whilst the Core tag is followed by a count of the reference number of the core, the end core tag has no tag value following it. Similarly the end of file tag (EOF) also has no tag value following it. But for simple data sets, this poses no real problem for reading and writing the file. For more complex data sets however, a more consistent data format is required, with a simple parser which can be called repetitively.
When I recently came to revisit the data file format for exporting data from my spreadsheets, I discovered XML files.
No need to re-invent the wheel, nor particularly any need to write a file parser as such, such file readers are built into various programming environments. The only task is having got the data, to sort it and assign to appropriate variables inside the user application: well programming wise. The bigger task is to decide on the format of the data.
I realise that MS Excel exports data to an XML file, newer may even use such as the default format, however that contains more information than I am interested in, and is about data defining a spreadsheet, not the structure of the data stored in the spreadsheet.
So at present I have wrapped the whole data set in the tag
Whilst writing this code in MS Excel/vba I also had problems dealing with Unicode characters, as Excel cells contained values which disappeared when written to a text file using the ordinary print functions. Having got the data into a text file also had problems reading them back in. But resolved the problems using the VBScript file system objects for reading and writing files.
The other problem encountered in the export of data to an XML file was that not all the named ranges were simple scalar values, some were lists and tables. So also added additional tags, if a range only lay on a single row or column, then the range classified as a list and tagged
- , if comprised of rows and columns then classified as a table and tagged . A list contains elements
An alternative format, or schema, I considered was to consider using the MS Excel range name as the XML tag, and then wrapping the value in these tags. The problem I had with that approach is that it is less generic. Whilst it may be the more valid way of defining the fields for a database in XML, it doesn't match what I already have in MS Excel and MS Access. In Excel all my variables are typically defined on one worksheet which is compatible with import into an MS Access table. In this way I can add new variables as I wish if I don't have need for a variable or more to the point if a program doesn't know what to do with the variable it can be ignored.
Whilst XML provides flexibility, and can easily write a new variable as a new XML tag, the problem is reading the XML file and then knowing what to do next with the data which comes after the tag. In effect an XML data file has to be parsed twice when using XML objects. The first level of parsing is to grab all the XML tags, any contained attributes, and then the data contained between the tags. The second level of parsing is determining what to do with the tags and data with respect to some specific application.
A book database with a fixed data structure is relatively simple: just read the XML file, and then permit searching and listing information about the list of books contained in the database. Throw variable data structures into the database, then need different processors for each data set found. For example with respect to CAD data, may have a circle and a line. A data structure for a circle contains say the diameter of the circle and may be its insertion point. The data structure for a line contains say the coordinates of the two ends of the line. Displaying a line on the screen is different than displaying a circle. So as the program works its way through all the data, it calls different commands to execute based on the data encountered at any given point in reading the data.
At the time of this experimenting, it seemed to me that if the variable name was used as a tag, then when read a variable unknown to the program, it would loose synchronisation with reading the rest of the file. {This may have had more to do with my writing a parser from scratch rather than using XML reader objects. Which is also why I didn't use parameter and variable as tag attributes. Something like isparameter=1}
If can read all the data into a XML tree object, then if traverse the tree and find a tag do not know, then can ignore the entire branch starting from that node. But if cannot read the entire data into an XML tree object, then seems to me, need to decide what to do as progress through the data: since cannot ignore an entire branch until identified the branch: found the end tag.
I don't know really, probably need to experiment with both approaches. Another approach adopted by some software is to use the tag attributes to contain data. This approach I don't like as it confuses things. Data is supposed to be between the tags, and the tags can contain attributes descriptive of the data. However storing data in the attributes can make the data file more compact and easier to read. For example, the definition of a node could be as follows:
<node id="1" x="2" y="5" z="0" />OR
<node>
<id>1</id>
<x>2</x>
<y>5</y>
<z>0</z>
</node>
And similarly I could have for simple variables or parameters.
<Height isparameter="1">5</Height >Compared to approach proposed above and otherwise experimented with:
<parameter>
<name>Height</name>
<value>5</value>
</parameter>
Parameters are input variables and can be changed, whilst those items I have named variables are dependent variables their value is dependent on the value of input parameters, and the process which relates the input to output. Change the process which relates the parameter to variable and change the output of the program. For example height and span could relate to a gable roof building or a skillion roof building or for that matter a balustrade. Thus two basic parameters can get transformed into a variety of structural forms. Further I can define a building as a series of bents. Each bent comprises one column and one rafter. To define a monoslope roof from bents, then the rafter would be split at mid point or any other convenient location along the rafter. Alternatively permit the bent to only comprise of a column. Any case the parameters height and span could occur multiple times and their meaning would vary depending on the object in which they are contained.
Say I throw another parameter in such as eavesHeight, then could have either of the following:
Method 1:
<eavesHeight isparameter="1">5</eavesHeight>Method 2 (preferred):
<parameter>
<name>eavesHeight</name>
<value>5</value>
</parameter>
Now why I prefer method 2, I'm not entirely sure. Method 2, is less compact and more cumbersome for a person to read than method 1. But ?I guess from my viewpoint, when I set up my spreadsheets I didn't know what the input parameters were. I simply worked through the calculations and unprotected certain values as parameters. I then shifted the input of these values to a worksheet used for input values. In Quatro Pro it was necessary to have all the input values to a dialogue box in a continuous block, and since I also wanted the data to be compatible with Paradox it also fell into place as one or more tables. Without the dialogue boxes it also seemed appropriate to collect similar data in sets, with one worksheet per set of data. So ended up with multiple tabbed sheets each of which was compatible with export to a database. When moved over to MS Excel and MS Access, the concept was maintained, even though can feed data from any where into a dialogue box.
So the tables or worksheets are not just a convenient place for named cells/ranges, its not just a simple matter of getting a value for a variable. The tables are defining the parameters which define the object which the spreadsheet is used to design.
So that the list of parameters and their names are just as important as the values of the parameters. Still doesn't give me a reason for putting the names between the XML tags rather than making them the XML tags. {I guess my reasoning is the parameters are data describing an object, change the object the parameters change. Therefore I have added another level of abstraction for the data, which may not be necessary.}
Any case that's the idea at present, if there is a named range in MS Excel then its value is exported to an XML file. If the data in an XML file is a parameter then it can be imported into an MS Excel worksheet. This way large spreadsheets do not have to be stored for individual projects, the MS Excel workbook just gets used as an application, and the required data is stored in simple XML files. This data can also be shared across different Excel workbooks which fulfil different functions. So all the data for a project can be stored in a central XML file, and used by a variety of applications. Each application just reads and writes the data it needs without messing up the data file for other applications.
Of course I could just use a simple Excel spreadsheet to get data to and from complex Excel workbooks, but that supposes Excel is available. Further not every suitable application will be built using Excel, plus XML is also useful for web based data storage. Which means faster development of a web based application at future date.
Looks like I need to figure out how to display the XML brackets. < and > is not working, and neither does using the actual characters. Take that back, it doesn't display correctly in compose. Now for the other problem: none of the sites I found providing a solution, actually explain properly what is required because the codes they recommend are translated and therefore see the results not the recommended codes. The results and codes are:
< is displayed by <
> is displayed by >
Tuesday, October 15, 2013
Feasibility of Cold-formed Steel Shed (Simple Structural Software Application)
The simplest program I have written to check the frames size of a cold-formed steel shed is EngineLT.exe. It is a cut down version of a larger program I wrote in Delphi 3, the problem with the larger program is I never really got round to working out how to get the Borland Database Engine (BDE) onto another machine, and I had more important things to do. So I ripped the database out, and simplified the interface. To give the following:
It is based on AS1170.2:1989, so its results are potentially no longer valid. But it provides a quick check on whether a given size of c-section is suitable for a given gable frame shed. A gable frame comprising of two rafters and two columns. The moments in the frame are calculated using Kleinlogel formula for a fixed base rigid moment frame.
The minimum sectional moment capacities of the available c-sections here in Australia are hard coded into the program. The minimum yield strength of the steel is 450MPa. Low internal pressure coefficients are adopted to reflect the status of the industry with respect to the standard calculations held by most suppliers. Remove one or both columns and get a different rigid frames, which are not within the scope of the program. Simply providing carry beams is not acceptable.
Roughly removing one column makes the roof a propped cantilever and the moment at the remaining knee is approximately 1.5 times the maximum knee moment in the full frame. Remove both columns and the maximum moment moves to the ridge and is approximately 3 times greater than it was in the full frame. Typically the maximum moment in the full frame is at the knee, but not always. Any case the program doesn't provide the details, nor can it handle these variations. The point is, the structural form is a specific rigid frame, any variation which changes this structural form requires a different mathematical model to check stresses in the frame.
It is common practice in the cold-formed shed industry to standardise frames at 3m centres and rip columns out for larger doors in the side: this changes the structural form and is beyond the scope of the standard calculations held by most shed suppliers. Merely providing carry beams is not adequate, in fact if remove too many columns, and want really large openings, an entirely different structural form may be required for the entire building: such as large parallel chord trusses span the entire length of the building, with two columns.
So before messing around with carry beams, the first check should be with changing the frame spacing. If want 5m wide doors then see what frame size is required for frames at 6m centres. Sure adopting 6m centres or larger means the C7510 girts/purlins typically used will no longer be valid. By adopting larger spaces, potentially reduce the amount of fabrication and onsite labour: though may increase the need for cranes.
Any case those are other design issues. When I wrote the program, my interest was providing a tool which would allow experimentation with something other than the standard 3m spacing. The application has no data files, and doesn't produce any result files or print any reports. It simply allows playing around with the basic input parameters, and seeing how they affect frame size. The frame size may not be possible when detail design is carried out due to lack of lateral torsional restraint to the frames: provided by combination of girts/purlins and flybracing. However if the program indicates a frame is not possible its highly unlikely that detailed design can make it possible.
EngineLt can be downloaded here as a zip file.
The frame size determined by the programme should be comparable to the frame size selected from the height/span design charts I have produced. The prime difference between the two is that the charts are to wind loading from AS1170.2:2002, whilst this program is to AS1170.2:1989.
Design Chart for C-Section Frames AS1170.2 Terrain Category 3 (TC3)
Design Chart for C-Section Frames AS1170.2 Terrain Category 2 (TC2)
DISCLAIMER :
Users of EngineLT must accept this disclaimer of warranty :
EngineLT is supplied as is. The author disclaims all warranties, expressed or implied, including without limitation, the warranties of merchantability and of fitness for any purpose. The author assumes no liability for damages, direct or consequential, which may result from the use of EngineLT .
It is based on AS1170.2:1989, so its results are potentially no longer valid. But it provides a quick check on whether a given size of c-section is suitable for a given gable frame shed. A gable frame comprising of two rafters and two columns. The moments in the frame are calculated using Kleinlogel formula for a fixed base rigid moment frame.
The minimum sectional moment capacities of the available c-sections here in Australia are hard coded into the program. The minimum yield strength of the steel is 450MPa. Low internal pressure coefficients are adopted to reflect the status of the industry with respect to the standard calculations held by most suppliers. Remove one or both columns and get a different rigid frames, which are not within the scope of the program. Simply providing carry beams is not acceptable.
Roughly removing one column makes the roof a propped cantilever and the moment at the remaining knee is approximately 1.5 times the maximum knee moment in the full frame. Remove both columns and the maximum moment moves to the ridge and is approximately 3 times greater than it was in the full frame. Typically the maximum moment in the full frame is at the knee, but not always. Any case the program doesn't provide the details, nor can it handle these variations. The point is, the structural form is a specific rigid frame, any variation which changes this structural form requires a different mathematical model to check stresses in the frame.
It is common practice in the cold-formed shed industry to standardise frames at 3m centres and rip columns out for larger doors in the side: this changes the structural form and is beyond the scope of the standard calculations held by most shed suppliers. Merely providing carry beams is not adequate, in fact if remove too many columns, and want really large openings, an entirely different structural form may be required for the entire building: such as large parallel chord trusses span the entire length of the building, with two columns.
So before messing around with carry beams, the first check should be with changing the frame spacing. If want 5m wide doors then see what frame size is required for frames at 6m centres. Sure adopting 6m centres or larger means the C7510 girts/purlins typically used will no longer be valid. By adopting larger spaces, potentially reduce the amount of fabrication and onsite labour: though may increase the need for cranes.
Any case those are other design issues. When I wrote the program, my interest was providing a tool which would allow experimentation with something other than the standard 3m spacing. The application has no data files, and doesn't produce any result files or print any reports. It simply allows playing around with the basic input parameters, and seeing how they affect frame size. The frame size may not be possible when detail design is carried out due to lack of lateral torsional restraint to the frames: provided by combination of girts/purlins and flybracing. However if the program indicates a frame is not possible its highly unlikely that detailed design can make it possible.
EngineLt can be downloaded here as a zip file.
The frame size determined by the programme should be comparable to the frame size selected from the height/span design charts I have produced. The prime difference between the two is that the charts are to wind loading from AS1170.2:2002, whilst this program is to AS1170.2:1989.
Design Chart for C-Section Frames AS1170.2 Terrain Category 3 (TC3)
Design Chart for C-Section Frames AS1170.2 Terrain Category 2 (TC2)
DISCLAIMER :
Users of EngineLT must accept this disclaimer of warranty :
EngineLT is supplied as is. The author disclaims all warranties, expressed or implied, including without limitation, the warranties of merchantability and of fitness for any purpose. The author assumes no liability for damages, direct or consequential, which may result from the use of EngineLT .
Subscribe to:
Posts (Atom)