Discussion Forum

A list of known bugs available on-line would be very interesting and might save some time for both us and the Comsol support engineers. A feature request board would also get my vote.

I find public bug tracking systems often confusing, with lots of duplicate bugs. It is better to do this through Comsol support, so there is some screening of the input.

Best regards,

Maarten.

Hi all,

Well I have a slightly different opinion, not against the idea of carefully tracking "bugs" to correct them, but on the real efficency of such an free open system, versus how to keep it up to date and how, as end user, to gain from it.

Take a global view:

First of all, what are "bugs" ? After about 3 years of intense use of COMSOL, in many domains, I have seen very few what I would really call "bugs", I beleive at most one per year, (such as variables that are wrongly updated, or wrongly named or matched when coupling all these physics).

But, I have seen quite some misinterpretetions of my understanding of the use of a variable, or a calculation method, and the COMSOL intended one. Just because of the complexity of all the physics involved. The COMSOL developpers had one idea, the user applies it to completely other case. This is often seen by the user as a "bug" but is mainly a misinterpretation of the tool and its internal methodolgy, which does need clarification and could be improved by updates of the software, but othen more on the documentation side.

Finally, I find a lot of "nice to have": these are suggestions to the COMSOL developpers how to avoid having me sitting there and clicking 50 times the same sequence, while I could have just had a simple tick box on the GUI.

Personally I do my best to document all these cases, and I submit them to COMSOL Support, by classify them as:
- suggestions (with screen shots written on where and what I would like to see, and then explaining in which case and why),
- clarification demands with simplified cases of my "problem" and explanations what I'm trying to perform. By setting up my clarification case (with a simple models of a particular feature), almost halve of them are resolved as suddenly I understand what I'm doing "wrong", in the sens going agains the methodology of the software. The others are efficiently treated by COMSOL Support and I get great answers back, but indeed sometimes it's "whait to next release".

On the large timescale, I see several of my suggestions coming in the newer releases, that's why I belive this works well, how it is.
This process takes me time, sure, but I also learn corectly how to use the programme, and searching through a Data Base just to try to understand the case of someone else would also take quite some time, without the same learning effect.

How many releases per year ?
It's interesting to notice that academics like to see the updates immediatly, and do not really care about a new release each month. But have they though about us others having to stand up and defend our results, with possible legal consequences ?

Take the case when you are building a bridge (or a plane ...), based on COMSOL calculations, it's you as engineer, NOT COMSOL as software supplier, that is responsible for the results. For each release you use, you MUST perform a certain number of checks by your own, to ensure integrity of YOUR results and tools, you do not want to do this each month, as this is unpaid time you are spending (but essential to have a minimum "quality" level acceptance by your customers).
We are working typically on 4-8 projects in parallel that last up to 5 years each, each require 3-5 different software tools, often linked by data exchange (and with data exchange with our customers and sub-co) you just cannot update all that each month, not even each year !


So, my conclusions are, when unexpected cases show up, close down on the culprit by simplifying the case and submit the case to the Support, if you havn't solved the case yourself by studying it in more detail, in which case you could document it in detail and post it to the Model Exchange column for us others.
It's better time spent than browsing through a DB with all sorts of "bug" cases not really like yours and not that simple to understand either.

Thanks for your time
Ivar

Ivar,

thanks for your opinion.

You are right with the fact that most of the "problems" of daily work relate to not understanding physics correctly (or, to be more precise, not to correctly map your own minds physics representation onto COMSOLs).

My daily work - I am not a researcher of any kind, but work in the product development - does not allow me to deeply track down every issue until I can reproduce it and know the exact circumstances. I need "quick" solutions, and looking for certain problems in a database would be a tremendous help to the question: Is it me or them?

I am talking of bugs - like what I saw during the last weeks when experimenting with the batch mode where certain things like plotting while solving lead to reproducible crashes. (I do know that it cannot plot while solving, but it should not crash anyway.) It took me a few hours to identify this really simple thing. Nobody pays us for that. - If one of our products fail, our customers charge us immediately for all the costs they have for that.

Maybe a public bug tracking system might really be too confusing. But why not have a list of known bugs?

If you look to other communitys - National Instruments has excellent ones - you will see that also feature requests are best discussed in public. It would create a wider base!

Best regards
Matthias

Hi Matthias

Well first good to know that I'm not allone to find my days stuck between my development activities (for my clients needs), and "updates" of the tools we use to get our work done (that I mostly do nightime becoming unpopular at home).
Because of this time pressure I didnt really study the cases when I got stuck, the first year; but being frustrated not getting what I wanted, I became more systematic and now I'm rather convinced that globally I'm winning time

My wish list for COMSOL is still far greater than what I can do myself, that's why I hope that this forums could lead to some more "script file exchanges" for doing tasks that are not implemented in the GUI but of rather common use, such as for structural simulations: standard model verifications procedures as per ESA or ESO quality documents, if not NAFEMS procedures (these I know less as not being member myself).

So back to the main topic, probably there is a better middleway between "no" bug report and everything in a DB, because DB needs still classifications and maintenance to be efficient.

Now the "Support Knowledge Base" of COMSOL could be updated also i this way, hope some COMSOL people are reading us from time to time ;)

Best regards
Ivar