|
Since several weeks the "SPICE Error Log" file contains these lines even when these transistors are not used:
Warning: Multiple definitions of model "2scr375p" Type: BJT
Warning: Multiple definitions of model "bc857b" Type: BJT
Warning: Multiple definitions of model "bc847c" Type: BJT
Warning: Multiple definitions of model "bc847b" Type: BJT
The multiple definitions are in c:\Users\...\AppData\Local\LTspice\lib\cmp\standard.bjt
E.g.
2SCR375P: Rohm, twice with identical parameters
BC847C: Duplicate from Rohm with wrong parameters, e.g. IKF=1.3 Vceo=32, Icrating=200m, base collector and base emitter capacities interchanged …
I am using LTspice version 17.1.9 and did never edit this model parameter file.
Does anyone know how the duplicates got in and how to avoid duplicates in the future?
Bernhard
|
I was just about to post
another example of this. In addition, I find in the netlist
generic devices NPN, PNP and D, which were in the .ASC but
have been replaced by real devices, BC547B, BC557B and 1N4148.
======================================================================================
Best wishes
John Woodgate OOO-Own Opinions Only
Rayleigh, Essex UK
I hear, and I forget.
I see, and I remember.
I do, and I understand.
Xunzi (340 - 245 BC)
On 2023-07-08 09:40, Bernhard Weiskopf
wrote:
toggle quoted message
Show quoted text
Since several weeks the "SPICE Error Log" file contains these lines even when these transistors are not used:
Warning: Multiple definitions of model "2scr375p" Type: BJT
Warning: Multiple definitions of model "bc857b" Type: BJT
Warning: Multiple definitions of model "bc847c" Type: BJT
Warning: Multiple definitions of model "bc847b" Type: BJT
The multiple definitions are in c:\Users\...\AppData\Local\LTspice\lib\cmp\standard.bjt
E.g.
2SCR375P: Rohm, twice with identical parameters
BC847C: Duplicate from Rohm with wrong parameters, e.g. IKF=1.3 Vceo=32, Icrating=200m, base collector and base emitter capacities interchanged …
I am using LTspice version 17.1.9 and did never edit this model parameter file.
Does anyone know how the duplicates got in and how to avoid duplicates in the future?
Bernhard
|
Interesting.
I have just tested with "NPN" and "D" but none of them are replaced acc. to the "SPICE Error Log" file (Ctrl+L).
But the multiple definitions of bjt models is still present.
My test file AF_Amp1.asc is in the Temp folder.
Bernhard
|
The deleted devices are in my
Netlist, not the Error Log.
======================================================================================
Best wishes
John Woodgate OOO-Own Opinions Only
Rayleigh, Essex UK
I hear, and I forget.
I see, and I remember.
I do, and I understand.
Xunzi (340 - 245 BC)
On 2023-07-08 10:31, Bernhard Weiskopf
wrote:
toggle quoted message
Show quoted text
Interesting.
I have just tested with "NPN" and "D" but none of them are replaced acc. to the "SPICE Error Log" file (Ctrl+L).
But the multiple definitions of bjt models is still present.
My test file AF_Amp1.asc is in the Temp folder.
Bernhard
|
I have the latest update to LTspice 17.1.9.
In my opinion, the transistor listing has reached a point where it canot be trusted.
? ? ? ? ? Anyone using the built in BJT listing needs to double or triple check any selected model.
I opened a schematic and placed 2 NPN devices.
I then tried to select the BC847C as my choice.
LTspice lists 2 models for this device.
The NXP mfg. listing shows a rating of 45V and 100 mA.
The ROHM mfg. listing shows a rating of 32V and 200 mA.
When you try to select the ROHM model for your BJT, LTspice automatically selects the NXP model.
Also, the spice model for the ROHM part is nothing more than completely worthless garbage.
The real model can be found here :
Additionally, the ROHM data sheet specifies 45V and 100 mA ratings.
I can only hope that someone at Analog Devices will spend time and clean up this mess.
Mike
|
On 08/07/2023 14:18, Mike Fraser wrote:
I have the latest
update to LTspice 17.1.9.
In my opinion, the transistor listing has reached a point where it
canot be trusted.
? ? ? ? ? Anyone using the built in BJT listing needs to double or
triple check any selected model.
I opened a schematic and placed 2 NPN devices.
I then tried to select the BC847C as my choice.
LTspice lists 2 models for this device.
The NXP mfg. listing shows a rating of 45V and 100 mA.
The ROHM mfg. listing shows a rating of 32V and 200 mA.
When you try to select the ROHM model for your BJT, LTspice
automatically selects the NXP model.
Also, the spice model for the ROHM part is nothing more than
completely worthless garbage.
The real model can be found here :
Additionally, the ROHM data sheet specifies 45V and 100 mA
ratings.
I can only hope that someone at Analog Devices will spend time and
clean up this mess.
You can hope, but don't hold your breath. The standard libraries
have been a mess for quite a while. I offered my help, but it wasn't
accepted.
--
Regards,
Tony
|
For BC847C Rohm offers the SPICE parameter set of BC547B. Therefore the current gain of the BC847C model is too low.
In the LTspice standard.bjt there are BC847B and BC847BT116, both from Rohm and with identical parameters (bloated file, T116 is only a delivery package).
Or look at the selection parameters for 2SCR542F3.
While its SPICE parameters are identical to 2SCR542P.
I agree with Tony, the standard libraries are indeed a mess.
I mostly use my own models. But the warnings caused by LTspice's own files that appear anyway, bother me.
Bernhard
|
Bernhard,
Those Warning messages about "Multiple definitions" of those four BJTs can be ignored.??The good news is that they are only Warnings.? And in your case, they do not affect your simulation, not one bit.??They have been there for years.? Your schematic did not cause them.
[Rant mode on.]
They got there because someone at Analog Devices put them there.
They are still there because Analog Devices is too inept to fix it.
Everyone who downloads LTspice gets a bad "standard.bjt" file.??(You get a bad "standard.jft" file too, but that'a for a different reason, and the mistakes in that one are very real and very bad, but that one is not entirely Analog Devices's fault and we won't get into that now.? It's been discussed already, separately.)? The "standard.bjt" file has duplicate entries for the 2scr375p, bc847b, bc847c, and bc857b.? LTspice gives you a warning whenever it sees duplicate definitions of any .MODEL statements, whether or not the model parameters actually differ.
Because your schematic has even one BJT on it, LTspice loads "standard.bjt" into your simulation, and bang, you get those warnings.
Like I said, you can safely ignore them.
I thought that if you update your models in LTspice, it might "fix" those duplicate definitions, and the warnings might go away.? Or maybe not.? The thousands of people who download LTspice daily are all being handed a bad copy of "standard.bjt" with these four mistakes in it -- and Analog Devices is too stupid to fix it.? Yes, they have been told about it.? But they do nothing about it.
Mike Engelhardt used to manage LTspice.? If he were still doing it, this problem would have been fixed years ago, and probably would not have happened in the first place.? But alas, he is no longer managing LTspice at Analog Devices.? Instead, we have other people including German Ergueta who are not up to Mike's standards, and appear to have no concept of library consistency.? Mr. Ergueta gave me a really lame sob-story about how long it takes to verify models, and garbage like that.? He totally misses the point.? To fix these four Warnings, all it would take is about 30 seconds with a text editor to remove the duplicates.? Done.? But Analog Devices is too lame to do a simple fix like that.
The good news is that you can ignore these Warning messages.? Unless you use one of those four transistor models, it won't affect you, not one bit.? Even if you did use one of those four transistors, you can relax because you are getting a real model, even if LTspice has a second model for the same transistor.? So it is not really a problem.? And anyway a Warning is just a Warning, it's not an Error.
The bad news is that Analog Devices seems to have no interest whatsoever in fixing their model libraries.? Until people like Mr. Ergueta and the other employees of Analog Devices who have a say in how LTspice works -- until they WAKE UP and fix simple problems like this instead of continuing to propagate it, it's going to be there forever.
Don't hold your breath.? Mr. Ergueta doesn't care that you have bad models, that could have and should have been fixed ages ago.
By the way, maybe you should take a look at QSPICE.? I recommend it as a replacement for the mistakes that Analog Devices seems to be unable or unwilling to fix.
[Rant mode off.]
FYI, you could eliminate those Warnings yourself by editing your "standard.bjt" and renaming the duplicate model names.? It's a plain text file and can be edited with a good text editor, including LTspice itself.
Andy
|
Mike Fraser wrote, "I can only hope that someone at Analog Devices will spend time and clean up this mess."
All of us wished that Analog Devices would do that.
But they are too inept to do that.
Andy
|
Hello Andy,
Thanks for the detailed words.
I know that the faulty libraries only cause warnings but no errors. But sometimes I do simulations, and the results are checked by other people. And that's where warnings don't look good.
In my standard.bjt file I deleted the five obviously faulty models and the warnings disappeared.
This will probably only remain until the next LTspice update. Hence my question as to whether the incorrect entries can be avoided in the future.
Even if I use components from ADI, there are almost always additional transistors in the circuit. I'm surprised that ADI ignores errors and warnings. I wasn't used to that from LTC.
I'm also registered in the QSPICE group, but haven't had time to deal with QSPICE in more detail so far. (Never change a …)
Bernhard
|
On Sat, Jul 8, 2023 at 10:15 AM, Andy I wrote:
Andy
I wonder if it might be worth the while of those of us concerned about Analog Device's inaction in these matters to take to social media to suggest alternatives to LTSpice. With apologies to Arlo Guthrie and his "Alice's Restaurant" and the Wikipedia site I pulled this from, "He predicts that a single person doing it would be rejected as "sick" and that two people doing it, in harmony, would be rejected as??"", but that once three people started doing it they would begin to suspect "an organization" and 50 people a day would be recognized as??a movement."
Thoughts?
|
There is also? JSPICE"JSPICE is a simulator for superconductor and semiconductor circuits, and is based on the general-purpose circuit simulation program SPICE2; it is incorporated with the Josephson junction model. It supports the same SPICE2 format and is running in the batch mode. Like SPICE2, it has ASCII plotting facility built in.? The simulator is only valid for transient simulations and DC operating point; AC small-signal analyses are not allowed."
On Sunday, July 9, 2023, 6:57:47 PM GMT+4, Christopher Paul <christopherrpaul1@...> wrote:
On Sat, Jul 8, 2023 at 10:15 AM, Andy I wrote:
Andy
I wonder if it might be worth the while of those of us concerned about Analog Device's inaction in these matters to take to social media to suggest alternatives to LTSpice. With apologies to Arlo Guthrie and his "Alice's Restaurant" and the Wikipedia site I pulled this from, "He predicts that a single person doing it would be rejected as "sick" and that two people doing it, in harmony, would be rejected as??"", but that once three people started doing it they would begin to suspect "an organization" and 50 people a day would be recognized as??a movement."
Thoughts?
|
Output is engraved on stone
tablets.
======================================================================================
Best wishes
John Woodgate OOO-Own Opinions Only
Rayleigh, Essex UK
I hear, and I forget.
I see, and I remember.
I do, and I understand.
Xunzi (340 - 245 BC)
On 2023-07-09 16:07, cander shelter via
groups.io wrote:
toggle quoted message
Show quoted text
There is also?
JSPICE
"JSPICE is a simulator for
superconductor and semiconductor circuits, and is based on
the general-purpose circuit simulation program SPICE2; it is
incorporated with the Josephson junction model. It supports
the same SPICE2 format and is running in the batch mode.
Like SPICE2, it has ASCII plotting facility built in.?
The simulator is only valid for transient simulations and
DC operating point; AC small-signal analyses are not
allowed."
On Sat, Jul 8, 2023 at 10:15 AM, Andy I wrote:
Andy
I wonder if it might be worth the while of those of us
concerned about Analog Device's inaction in these
matters to take to social media to suggest alternatives
to LTSpice. With apologies to Arlo Guthrie and his
"Alice's Restaurant" and the Wikipedia site I pulled
this from,
"He
predicts that a single person doing it would be
rejected as "sick" and that two people doing it, in
harmony, would be rejected as??"", but
that once three people started doing it they would
begin to suspect "an organization" and 50 people a day
would be recognized as??a
movement."
Thoughts?
|
Hello All,
Members could maintain a set of the standard.xxx files for use by the group. I've been doing that for many years now. If the group retained a set of maintained files in an easy to reach repository similar to /files/temp, group members could downloaded them when needed to replace the LTspice versions that appear after an LTspice update. I have a set of standard.xxx files that I have maintained across LTspice updates since LTspice IV was all the rage.
?????????????????????? ? ?? # OF DEVICES
FILE??????????????? MAINTAINED? LTspice
standard.bjt?? ? ? ?? 1875 ?????? ?? 306 standard.dio???????? 2575 ?????? ?? 928 standard.jft ? ?????? 1306??????????? 140 standard.mos????? 1710????????? 1207
The library files could be kept in a single zip that could be easily dropped onto the \cmp directory to clobber the undesirable LTspice official standard.xxx files after an LTspice update. Of course there are no guaranties of model quality from anyone including the author of LTspice but, I much prefer having 1875 BJT models to choose from as opposed to the 306 model provided by AD.
The paradigm could then be changed from "missing BJT model, be sure to include your model in your working directory" to "Missing BJT model, be sure to download the set of standard.xxx files from the group." Then group members could leave the substandard standard.xxx files to suffer the rest of the world.
If I knew anything about PC programming, I would write something to move the maintained files out of the way, call LTspice into update mode, combine any new devices into the maintained files and finally overwrite the downloaded LTspice files. But, I don't. I write embedded system code in assembler and C, where I get to roll all my own code. I have no idea how to deal with calling a zillion pieces of somebody else's code to piece together a PC program. So I just maintain my own copies of the standard.xxx files that I process in a text editor. Back in the 90's I used to easily accomplished such tasks with dBase/Clipper but that capability disappeared for me when M$ abandoned 16-bit software altogether.
All for now
|
It sounds a very good idea, but
keeping the same filenames could cause untold confusion. Is
there any way of making the names different?? The only thing I
can think of is making them all upper-case, i.e. STANDARD.BJT
etc., which humans see as different but LTspice doesn't.
======================================================================================
Best wishes
John Woodgate OOO-Own Opinions Only
Rayleigh, Essex UK
I hear, and I forget.
I see, and I remember.
I do, and I understand.
Xunzi (340 - 245 BC)
On 2023-07-09 19:21, eewiz wrote:
toggle quoted message
Show quoted text
Hello All,
Members could maintain a set of the standard.xxx files for
use by the group.
I've been doing that for many years now.
If the group retained a set of maintained files in an easy to
reach repository similar to /files/temp, group members could
downloaded them when needed to replace the LTspice versions that
appear after an LTspice update.
I have a set of standard.xxx files that I have maintained
across LTspice updates since LTspice IV was all the rage.
?????????????????????? ? ?? # OF DEVICES
FILE??????????????? MAINTAINED? LTspice
standard.bjt?? ? ? ?? 1875 ?????? ?? 306
standard.dio???????? 2575 ?????? ?? 928
standard.jft ? ?????? 1306??????????? 140
standard.mos????? 1710????????? 1207
The library files could be kept in a single zip that could be
easily dropped onto the \cmp directory to clobber the
undesirable LTspice official standard.xxx files after an LTspice
update.
Of course there are no guaranties of model quality from
anyone including the author of LTspice but, I much prefer having
1875 BJT models to choose from as opposed to the 306 model
provided by AD.
The paradigm could then be changed from "missing BJT model,
be sure to include your model in your working directory" to
"Missing BJT model, be sure to download the set of standard.xxx
files from the group."
Then group members could leave the substandard standard.xxx
files to suffer the rest of the world.
If I knew anything about PC programming, I would write
something to move the maintained files out of the way, call
LTspice into update mode, combine any new devices into the
maintained files and finally overwrite the downloaded LTspice
files.
But, I don't. I write embedded system code in assembler and
C, where I get to roll all my own code.
I have no idea how to deal with calling a zillion pieces of
somebody else's code to piece together a PC program.
So I just maintain my own copies of the standard.xxx files
that I process in a text editor.
Back in the 90's I used to easily accomplished such tasks
with dBase/Clipper but that capability disappeared for me when
M$ abandoned 16-bit software altogether.
All for now
|
I'm not against a repository of models - we already have one in the group 's Files section. But I am against trying usurp the standard libraries. Most people coming to this group, at least initially, will have only the installation files. Once people have learnt to deal with 3rd party models, they can use what they want. We have had endless issues over the years with people adding extra models to the standard libraries and then wondering why no one can run their problematic schematics, when they believe they have uploaded everything necessary. Many of us of us are not satisfied with ADI's chaotic recent efforts with the standard libraries, but the solution is not additional chaos. Although this is a big group, it still only represents a fraction of the LTspice user base. We may not like the current situation, but we need to concentrate on enabling people to use LTspice despite the current issues, by freeing them from the initial dependency on the standard libraries. ADI's current preoccupation is making sure that their own example schematics run with what is what is currently in the standard libraries. That is where they see the critical value-added issues. People complaining about multiple BC848s are way down in the noise, because they are probably not buying lots of ADI's premium products. For heaven's sake, even the multiple BC848s issue is trivial compared to the dozens of JFETs in that library that have massively faulty models. If anything, I think emphasis ought to be on educating users to validate whatever models they are using. Quality trumps quantity. What's the value in having 1875 BJT models that have little to zero provenance? Have you validated any of them? German Ergueta is right when he says that validation is a time consuming issue. I'd like to think that's because he has lots of people validating things. He probably does - just not the standard libraries. Could we do a better job? Possibly. But who's going to do the heavy lifting?? And not get paid for doing it. And would it have a global impact? No.
-- Regards, Tony?
On 9 Jul 2023 20:21, eewiz <eewiz@...> wrote:
Hello All,
Members could maintain a set of the standard.xxx files for use by the group. I've been doing that for many years now. If the group retained a set of maintained files in an easy to reach repository similar to /files/temp, group members could downloaded them when needed to replace the LTspice versions that appear after an LTspice update. I have a set of standard.xxx files that I have maintained across LTspice updates since LTspice IV was all the rage.
?????????????????????? ? ?? # OF DEVICES
FILE??????????????? MAINTAINED? LTspice
standard.bjt?? ? ? ?? 1875 ?????? ?? 306 standard.dio???????? 2575 ?????? ?? 928 standard.jft ? ?????? 1306??????????? 140 standard.mos????? 1710????????? 1207
The library files could be kept in a single zip that could be easily dropped onto the \cmp directory to clobber the undesirable LTspice official standard.xxx files after an LTspice update. Of course there are no guaranties of model quality from anyone including the author of LTspice but, I much prefer having 1875 BJT models to choose from as opposed to the 306 model provided by AD.
The paradigm could then be changed from "missing BJT model, be sure to include your model in your working directory" to "Missing BJT model, be sure to download the set of standard.xxx files from the group." Then group members could leave the substandard standard.xxx files to suffer the rest of the world.
If I knew anything about PC programming, I would write something to move the maintained files out of the way, call LTspice into update mode, combine any new devices into the maintained files and finally overwrite the downloaded LTspice files. But, I don't. I write embedded system code in assembler and C, where I get to roll all my own code. I have no idea how to deal with calling a zillion pieces of somebody else's code to piece together a PC program. So I just maintain my own copies of the standard.xxx files that I process in a text editor. Back in the 90's I used to easily accomplished such tasks with dBase/Clipper but that capability disappeared for me when M$ abandoned 16-bit software altogether.
All for now
|
Some valid points, but I think
the proposal is not 'either/or'. I see no objection to putting
the expanded files in a new subfolder of Files, as long as it
has a warning about how to use it and not use it.
Not everyone has Tony's skills
in verifying a model. Some of us need more support.
======================================================================================
Best wishes
John Woodgate OOO-Own Opinions Only
Rayleigh, Essex UK
I hear, and I forget.
I see, and I remember.
I do, and I understand.
Xunzi (340 - 245 BC)
On 2023-07-09 22:02, Tony Casey wrote:
toggle quoted message
Show quoted text
I'm not against a repository of models - we already have
one in the group 's Files section. But I am against trying
usurp the standard libraries.
Most people coming to this group, at least
initially, will have only the installation files.
Once people have learnt to deal with 3rd party
models, they can use what they want.
We have had endless issues over the years with
people adding extra models to the standard libraries and
then wondering why no one can run their problematic
schematics, when they believe they have uploaded everything
necessary.
Many of us of us are not satisfied with ADI's
chaotic recent efforts with the standard libraries, but the
solution is not additional chaos. Although this is a big
group, it still only represents a fraction of the LTspice
user base.
We may not like the current situation, but we
need to concentrate on enabling people to use LTspice
despite the current issues, by freeing them from the initial
dependency on the standard libraries.
ADI's current preoccupation is making sure
that their own example schematics run with what is what is
currently in the standard libraries. That is where they see
the critical value-added issues.
People complaining about multiple BC848s are
way down in the noise, because they are probably not buying
lots of ADI's premium products. For heaven's sake, even the
multiple BC848s issue is trivial compared to the dozens of
JFETs in that library that have massively faulty models.
If anything, I think emphasis ought to be on
educating users to validate whatever models they are using.
Quality trumps quantity. What's the value in having 1875 BJT
models that have little to zero provenance? Have you
validated any of them?
German Ergueta is right when he says that
validation is a time consuming issue. I'd like to think
that's because he has lots of people validating things. He
probably does - just not the standard libraries.
Could we do a better job? Possibly. But who's
going to do the heavy lifting?? And not get paid for doing
it. And would it have a global impact? No.
-- Regards,
Tony?
|
Alexander Bordodynov's greatly expanded standard.xxx libraries have been available for years. Alex is a highly valued member of the group. I don't know the provenance of the models in his collection, but I know it includes lots of Russian devices that many of us probably can't obtain. A minority users have stated they use them. Good luck to them. But when it comes to fielding questions related to models they have got from there but have forgotten they did so, what are we supposed to do? Collections of models uploaded to the group's files section are welcome. Even better when they have some sort of traceability or QA. People can use them in the usual 3rd party mode, with the usual proviso of caveat emptor. The ideal situation is that ADI have dozens of testers validating thousands of models that we can trust. That's not the reality. I recently uploaded a MOSFET model that I developed from the datasheet. I provided a report that compared the model's output to the datasheet. People can make up their own minds about that. It took me about a day to do it, and I have a set of prepared jigs and spreadsheets that have evolved over the years. On that basis it would take me over 5 years to validate 1875 BJT models if I didn't have anything else to do. But... we don't need 1875 BJTs. Most likely, many of them are not even available any more. Many devices are so similar that in 98% of cases, they are completely interchangeable. We don't need 10 devices that are essentially the same. But some are not. There are few alternatives to the Onsemi ring emitter high power audio BJTs, especially the ThermalTrak ones, for example. Sadly, they aren't in the standard library. You can download them from Onsemi. You can also download a sub-set of those (and others) from Bob Cordell's website, that he produced to address supposed deficiencies in the models from Onsemi - you can get those . Bob is a highly respected audio designer, but as far as I know neither he nor Onsemi have published any quality control documents on the efficacy of said models. Instead, there are usually disclaimers (from manufacturers) to not rely on them. Say what? Some people often say you can't trust simulations -? that you must build and test every circuit. Maybe they're right on that basis. I guess when Intel introduce a new processor with 10 billion transistors, they have previously made a dozen or so cut'n'strap breadboards to prove it works. As far as I can tell, ADI are not validating discrete devices for the standard.xx libraries. Instead there are periodic announcements of xxx devices kindly contributed by XYZ Semiconductor Corporation. But when we check (I mean "I"), these are not always the same as those directly available from the original producer's website. In the case of the JFETs, we must therefore conclude they have been mangled by ADI in the process of translation to the standard library file format. As far as I'm concerned, I would rather have 100 models I can trust, rather than a 1000 that I can't. At the moment, it seems, we don't have either.
--
Regards,
Tony
On 10/07/2023 00:05, John Woodgate wrote:
Some valid points, but I think the proposal is not 'either/or'. I see no objection to putting the expanded files in a new subfolder of Files, as long as it has a warning about how to use it and not use it.
Not everyone has Tony's skills in verifying a model. Some of us need more support.
|
I have searched for this and can't find anything that is generic and at my level but, is there somewhere information on a sensible validation procedure for the simple classes of model?? I mean something like at best a tutorial video going through the process, or a description of the process and what needs to be validated, or maybe at least a simple step by step guide.? I do hear what you experts say on the models being flawed and it would be good to verify the ones we each use regularly.? It's an area I have al;ways meant to dip into but I've never been able to address the first step.
|
You put your device and its
model into a curve-tracer .ASC and set it up to produce (if it
will) the same curves as in the data sheet. Compare the
results. You can find curve-tracer .ASCs by going to Files on
the web site and Searching for 'curve tracer'. For a bipolar,
I would start with collector current as a function of
collector voltage with base current as parameter. But remember
the large variation of current gain between samples, even for
graded devices like BC847x.
======================================================================================
Best wishes
John Woodgate OOO-Own Opinions Only
Rayleigh, Essex UK
I hear, and I forget.
I see, and I remember.
I do, and I understand.
Xunzi (340 - 245 BC)
toggle quoted message
Show quoted text
I have searched for this and can't find anything that is generic
and at my level but, is there somewhere information on a sensible
validation procedure for the simple classes of model?? I mean
something like at best a tutorial video going through the process,
or a description of the process and what needs to be validated, or
maybe at least a simple step by step guide.? I do hear what you
experts say on the models being flawed and it would be good to
verify the ones we each use regularly.? It's an area I have
al;ways meant to dip into but I've never been able to address the
first step.
|
John Woodgate
Tony Casey
eewiz